At 09:05 PM 9/11/2006 +0200, Elvelind Grandin wrote:
>I was supriced that the following code returns True.
>parse_version("0.1dev") > parse_version("0.1rc")
>A rc release should in my mind be newer then a dev version.
This is because 'rc' is treated the same as 'c', which in turn is less than
'dev'.
At 06:47 PM 9/8/2006 -0700, David Primmer wrote:
>I've recently figured out how to do wsgi with IIS
><http://pylonshq.com/project/pylonshq/wiki/ServePylonsWithIIS>http://pylonshq.com/project/pylonshq/wiki/ServePylonsWithIIS
>But I have problem with setuptools. If I have any zip eggs used by the app
>I'm trying to serve with IIS, I get a dependency not found error. If I
>remove the .egg zip files and re-download those same packages with
>--always-unzip, they work fine. There seems to be something preventing
>zipimport from working.
I'm afraid I haven't got a clue on this one. I can't think of any problem
that would cause you to get a DependencyNotFound error with a .egg file
that wouldn't do the exact same thing for an .egg directory.
There are other kinds of errors I can think of that might happen for one
and not the other, but DependencyNotFound isn't one of them.
I was supriced that the following code returns True.
parse_version("0.1dev") > parse_version("0.1rc")
A rc release should in my mind be newer then a dev version.
Turbogears has a problem with this regarding SQLObject. TG requires
SQLObject 0.7.1dev-r1860 but can't use SQLObject 0.7.1rc1 which is a
newer release.
--
cheers
elvelind grandin
I've recently figured out how to do wsgi with IIS
http://pylonshq.com/project/pylonshq/wiki/ServePylonsWithIIS
But I have problem with setuptools. If I have any zip eggs used by the app
I'm trying to serve with IIS, I get a dependency not found error. If I
remove the .egg zip files and re-download those same packages with
--always-unzip, they work fine. There seems to be something preventing
zipimport from working.
thanks.
davep
From PEP 302:
The load_module() method has a few responsibilities that it must
fulfill *before* it runs any code:
- If there is an existing module object named 'fullname' in
sys.modules, the loader *must* use that existing module.
(Otherwise, the reload() builtin will not work correctly.)
If a module named 'fullname' does not exist in sys.modules,
the loader must create a new module object and add it to
sys.modules.
(emphasis on must)
The current implementation always reloads the module if it exists. This
problem exists in both the 0.6 and 0.7 series. Since pkgutil is in Python
2.5, this is an issue there as well.
--
Jeremy Kloth
http://4suite.org/
At 09:14 AM 9/8/2006 -0400, Kevin Dangoor wrote:
>I've had quite a few complaints over the months from people who are
>stuck behind firewalls and can't install TurboGears with easy_install
>for whatever reason. This problem is somewhat compounded in cases
>where the user may have a machine that has internet access, but isn't
>the same platform as their deployment machine so they wouldn't even
>get the right eggs to deploy with easy_install.
>
>What I ultimately want to end up with is a tarball that contains all
>of the platform independent stuff, and then three tarballs for the
>platform dependent stuff (win, mac, source).
>
>I know about easy_install -zmaxd, and that certainly helps... but
>
>1) it doesn't keep all of the eggs zipped up (because it sitll thinks
>it's doing an install, instead of just a download)
Huh? -z should force it to never unzip eggs. Are you sure it's doing that?
>2) it doesn't help with the three platform dependent parts
>
>Is this something zc.buildout can help with? I'm not certain what the
>best way is to automate this process...
If I were in your shoes, I'd certainly take a look at zc.buildout, although
I don't know if it has everything you'll need.
It would be nice, though, if you ended up with a tool that could be used to
build a tarball bundle of any project, not just turbogears. Bonus points
if the tarball contains everything in --single-version-externally-managed
form, so somebody can just extract it and put it in a directory on
PYTHONPATH. ;)
(Note that to create the SVEM form of an egg, you just rename the EGG-INFO
directory to package-version-pyver-platform.egg-info during extraction; an
easy trick using setuptools.archive_util.)
Oh, and extra extra bonus points if this thing can become something like
"bdist_eggbundle" and was usable via setuptools. Then, you could just run
something like "setup.py bdist_eggbundle --platform=XXX" to build one for
each platform. :)
Hello,
Is it possible to automate building of extensions using xmingw when you
do a bdist_wininst?
if not, what is the recommended way to cross-compile extension modules
on a linux box, targeting windoze?
i am particularly interested in f2py extension modules.
any help is greatly appreciated.
Flávio
Please upgrade and report any problems promptly; I plan to release this
version as 0.6 final if there are no bug reports over the next week or so.
Bug fixes since 0.6c1 include:
* The ``ez_setup`` module displays the conflicting version of setuptools
(and its installation location) when a script requests a version that's
not available.
* Running ``setup.py develop`` on a setuptools-using project will now
install setuptools if needed, instead of only downloading the egg.
* Fix a problem with eggs specified directly on ``PYTHONPATH`` on
case-insensitive filesystems possibly not showing up in the default
working set, due to differing normalizations of ``sys.path`` entries.
* Windows script wrappers now support quoted arguments and arguments
containing spaces. (Patch contributed by Jim Fulton.)
* The ``ez_setup.py`` script now actually works when you put a
setuptools ``.egg`` alongside it for bootstrapping an offline machine.
* A writable installation directory on ``sys.path`` is no longer required
to download and extract a source distribution using ``--editable``.
* Generated scripts now use ``-x`` on the ``#!`` line when
``sys.executable`` contains non-ASCII characters, to prevent
deprecation warnings about an unspecified encoding when the script
is run.
At 12:34 PM 9/6/2006 -0400, Kevin Dangoor wrote:
>On 9/6/06, Phillip J. Eby <pje(a)telecommunity.com> wrote:
>>Maybe you should do this:
>>
>> >>> import pkg_resources
>> >>> print list(pkg_resources.working_set)
>> >>> print sys.path
>>
>>And send me the result.
>
>OK, here goes:
>
>>>>import sys
>>>>import pkg_resources
>>>>print list(pkg_resources.working_set)
>[setuptools 0.6c1
>(/usr/local/lib/python2.4/site-packages/setuptools-0.6c1-py2.4.egg),
>nose 0.9.0 (/usr/local/lib/python2.4/site-packages)]
Aha! It just occurred to me that a bug I thought was fixed in 0.6c1 is
actually only fixed in 0.6c2 (not yet released).
Could you try installing 0.6.c2dev-r50757, via:
easy_install setuptools==dev06
and see if that fixes your problem? I think this is an already-fixed
bug. I thought it was limited to case-insensitive filesystems (e.g.
Windows), but it looks like it would also apply to symlinks, and produce
the results you're seeing.
At 09:00 AM 9/6/2006 -0400, Kevin Dangoor wrote:
>On 9/6/06, Phillip J. Eby <pje(a)telecommunity.com> wrote:
>>At 01:07 PM 9/5/2006 -0700, Kevin Dangoor wrote:
>> >On 9/1/06, Phillip J. Eby <pje(a)telecommunity.com> wrote:
>> >>I think you're going to need to be more specific here. I'm not clear on
>> >>what is being found when, by what. I'm also not clear what is being
>> >>symlinked where.
>> >
>> >OK, here are specifics....
>> >
>> >Things in /base/pkg/Foo/usr/local/lib/python2.4/site-packages are
>> >linked over to /usr/local/lib/python2.4/site-packages. (I doubt it
>> >makes a difference, but this whole thing is actually run in a chrooted
>> >environment...) It appears that in most instances (and I don't know
>> >enough about the packager to know which instances and why), the
>> >directories are real directories, but the files inside are symlinks.
>> >Specifically:
>> >
>> >/usr/local/lib/python2.4/site-packages/nose would be a real directory
>> >/usr/local/lib/python2.4/site-packages/nose/result.py is a symlink to
>> >/base/pkg/Foo/usr/local/lib/python2.4/site-packages/nose/result.py
>> >
>> >There's a nose-0.9.0-py2.4.egg-info directory next to the nose
>> >directory (again, the directory is real but the files inside are
>> >symlinks).
>> >
>> >One more important thing to know about this setup. We have a couple of
>> >different packages in /base/pkg, and they both contribute to
>> >/usr/local/lib...
>> >
>> >When you run python, the /baes/pkg... path for the package that
>> >contains Python is what shows up in sys.path (not
>> >/usr/local/lib/python2.4/site-packages). We created a sitecustomize.py
>> >file to add /usr/local/lib/python2.4/site-packages as a sitedir. We're
>> >able to import all of the python packages from that directory just
>> >fine. But, I wrote a nose plugin that is only found if I explicitly
>> >set a PYTHONPATH environment variable to point to
>> >/usr/local/lib/python2.4/site-packages.
>> >
>> > From the Python prompt, if I iter_entry_points, I don't see my plugin
>> >without the PYTHONPATH. However, I can require my package and see the
>> >entry point via the API.
>> >
>> >Hopefully that makes it clearer...
>>
>>Not by much, I'm afraid. You haven't answered these questions:
>>
>>* Is the plugin on sys.path?
>
>Yes. Twice it turns out... It first appears in the
>/base/pkg/MainPackage/usr/local/lib/python2.4/site-packages location,
>and then the symlinked one (mentioned in my earlier message) appears
>in /usr/local/lib/python2.4/site-packages which is added to sys.path
>via sitecustomize (site.addsitedir). Running "python" from the command
>line and looking at sys.path shows both of these locations.
>
>(Note that Nose itself appears in /base/pkg/DevPackage/... and is then
>symlinked into the /usr/local/lib... space, the locations above are
>the ones for my Nose plugin.)
>
>>* How is the plugin installed? Develop? .egg? .egg-info?
>
>.egg-info
>
>this may be relevant... the python package is called something like
>"foobar" and the egg-info is "FOOBar-1.0-py2.4.egg-info". As I
>mentioned, pkg_resources is able to find it.
>
>>* Where is it installed?
>
>see above
>
>>Note that a plugin has to be on sys.path for its entry points to show up,
>>so it almost sounds to me like there's no problem here and everything is
>>behaving normally.
>>
>>What would be weird would be if it *did* show in iter_entry_points
>>*without* being on sys.path, or if it were on sys.path, but not showing up
>>in iter_entry_points.
>
>Since I was following the single-version-externally-managed model with
>an egg-info directory, the egg with the plugin doesn't appear directly
>on sys.path.
Huh? Above you said it did. Which is it?
Maybe you should do this:
>>> import pkg_resources
>>> print list(pkg_resources.working_set)
>>> print sys.path
And send me the result.
> Here's the kicker, though, if I set the PYTHONPATH
>environment variable to /usr/local/lib/python2.4/site-packages the
>plugin does show up in iter_entry_points. Doing that has the effect of
>putting the /usr/local/lib... symlinked version before the "real"
>version in /base/pkg/MainPackage on the sys.path.
>
>Also, I'm effectively running as root, so there shouldn't be any
>permissions issues involved.
That's not likely the problem. pkg_resources does a lot of
os.realpath()-ing to ensure it's using canonical paths; it's more likely
that there's some place where the difference between the "real" path and
the version that's on sys.path is causing a problem. Assuming, of course,
that there is in fact a problem, which I'm not yet convinced of because
your statements above appear inconsistent, although that's probably because
you're using more than one definition of what "on sys.path" means.
