Distutils-SIG September 2006

distutils-sig@python.org

26 participants
54 discussions

by Phillip J. Eby

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'.

13 years, 10 months

Re: [Distutils] zip eggs not accessible when running setuptools under IIS

by Phillip J. Eby

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.

13 years, 10 months

setuptools dev > rc.

by Elvelind Grandin

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

13 years, 10 months

zip eggs not accessible when running setuptools under IIS

by David Primmer

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

13 years, 11 months

[setuptools] Bug in setuptools ImpLoader

by Jeremy Kloth

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/

13 years, 11 months

Re: [Distutils] [setuptools] best way to create offline install bundles?

by Phillip J. Eby

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. :)

13 years, 11 months

distutils and xmingw

by Flavio Codeco Coelho

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

13 years, 11 months

setuptools 0.6c2 released

by Phillip J. Eby

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.

13 years, 11 months

Re: [Distutils] problem finding an entry point

by Phillip J. Eby

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.

13 years, 11 months

Re: [Distutils] problem finding an entry point

by Phillip J. Eby

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.

13 years, 11 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Distutils-SIG September 2006