pkg_resources: failed require

I notice when I install into app-packages/, then do:
But if I fix sys.path immediately, then it does work, so the failure seems to be sticky. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org

At 02:54 AM 5/30/2005 -0500, Ian Bicking wrote:
That's very odd; require() doesn't do any caching. Even the PEP 302-defined caching (sys.path_importer_cache) is from *particular* path entries (e.g. app-packages) to importer objects created for them. So if app-packages wasn't on sys.path, it never would've had anything cached. Are you able to reliably reproduce the double-failure condition? Is the error message the same each time?

Phillip J. Eby wrote:
Hmm... I think I got it wrong, this works fine. Maybe I was confusing this with a bug related to packages with spaces in their names. In particular, WSGIUtils: http://www.owlfish.com/software/wsgiutils/downloads/WSGI%20Utils-0.5.tar.gz I suspect this doesn't work because it creates an egg WSGI_Utils-0.5-py2.4.egg/, with a package name (in WSGI_Utils-0.5-py2.4.egg/EGG-INFO/PKG-INFO) of "WSGI Utils" -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org

Ian Bicking wrote:
Hmm... maybe I'm just confused about how this stuff works. You don't require a Python package name, you require the more abstract name. But case insensitive. So require("wsgi-utils") or require("WSGI_Utils") works, but require('wsgiutils') doesn't. Since require('sqlobject') worked (even though the package name is SQLObject) I had become confused by this. So, not a bug. But definitely confusing. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org

At 02:58 PM 5/30/2005 -0500, Ian Bicking wrote:
Right; you require() the distribution name. I should probably find some examples that clearly use the distribution name. Maybe wxPython would be good, since the distribution is wxPython, but the package is wx. So you "require('wxPython>=2.5')", for example. I'll try to update the docs to make this clearer. And maybe if you install in --multi-version mode or to an alternate directory, easy_install should spit out a couple of example require() spellings for you to use, maybe even copy and paste right into your code. Perhaps something like: """ Installed WSGI_Utils-0.5-py2.4.egg Because this distribution was installed --multi-version or --install-dir, before you can import modules from this package in an application, you will need to 'import pkg_resources' and then use a 'require()' call similar to one of these examples, in order to select the desired version: pkg_resources.require("WSGI-Utils==0.5") # this exact version pkg_resources.require("WSGI-Utils>=0.5") # this version or higher pkg_resources.require("WSGI-Utils") # latest installed version Note also that '/your/instdir/setting' must be on sys.path at runtime for this to work. (e.g. by being the application script directory, by being on PYTHONPATH, or by being added to sys.path by your code.) """ I'll look into about adding a post-install report with this information for multi-version and alternate-directory installs. (That last paragraph above about '/your/instdir/setting' would only appear for --install-dir installs, and would include the actual directory name.)
Yeah, I really didn't want to make it possible to have 'SQLobject' and 'sqlobject' both exist as distributions (even though I believe PyPI currently allows that). It would be just too darn confusing to make a typo and end up with the entirely wrong product, once we have automatic package location via PyPI et al.

At 02:44 PM 5/30/2005 -0500, Ian Bicking wrote:
What do you mean by "this doesn't work"? Currently, the egg runtime never reads anything out of PKG-INFO except for the 'Version' field. So, although the 'Name' field reads "WSGI Utils", it is still recognized as the 'WSGI_Utils' package by 'require()'. What it *won't* be recognized as, is 'WSGI Utils', which is a requirement syntax error since package names in requirement specs can't have spaces in them. You're probably right, though, that the PKG-INFO file 'Name:' should match the actual egg name, so I've made that change and it should go out in 0.3a3. (The 'Name:' will read 'WSGI-Utils'). Note that egg names can currently only contain alphanumeric characters, '_', or '-'. And those last two are interchangeable, as '-' is converted to '_' in the egg's actual filename. Spaces in the setup(name="") argument are converted to '-'. It's possible that this range could/should be expanded somewhat, but it seemed prudent to be conservative initially, since it's easier to add capability than to take it away.

At 02:54 AM 5/30/2005 -0500, Ian Bicking wrote:
That's very odd; require() doesn't do any caching. Even the PEP 302-defined caching (sys.path_importer_cache) is from *particular* path entries (e.g. app-packages) to importer objects created for them. So if app-packages wasn't on sys.path, it never would've had anything cached. Are you able to reliably reproduce the double-failure condition? Is the error message the same each time?

Phillip J. Eby wrote:
Hmm... I think I got it wrong, this works fine. Maybe I was confusing this with a bug related to packages with spaces in their names. In particular, WSGIUtils: http://www.owlfish.com/software/wsgiutils/downloads/WSGI%20Utils-0.5.tar.gz I suspect this doesn't work because it creates an egg WSGI_Utils-0.5-py2.4.egg/, with a package name (in WSGI_Utils-0.5-py2.4.egg/EGG-INFO/PKG-INFO) of "WSGI Utils" -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org

Ian Bicking wrote:
Hmm... maybe I'm just confused about how this stuff works. You don't require a Python package name, you require the more abstract name. But case insensitive. So require("wsgi-utils") or require("WSGI_Utils") works, but require('wsgiutils') doesn't. Since require('sqlobject') worked (even though the package name is SQLObject) I had become confused by this. So, not a bug. But definitely confusing. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org

At 02:58 PM 5/30/2005 -0500, Ian Bicking wrote:
Right; you require() the distribution name. I should probably find some examples that clearly use the distribution name. Maybe wxPython would be good, since the distribution is wxPython, but the package is wx. So you "require('wxPython>=2.5')", for example. I'll try to update the docs to make this clearer. And maybe if you install in --multi-version mode or to an alternate directory, easy_install should spit out a couple of example require() spellings for you to use, maybe even copy and paste right into your code. Perhaps something like: """ Installed WSGI_Utils-0.5-py2.4.egg Because this distribution was installed --multi-version or --install-dir, before you can import modules from this package in an application, you will need to 'import pkg_resources' and then use a 'require()' call similar to one of these examples, in order to select the desired version: pkg_resources.require("WSGI-Utils==0.5") # this exact version pkg_resources.require("WSGI-Utils>=0.5") # this version or higher pkg_resources.require("WSGI-Utils") # latest installed version Note also that '/your/instdir/setting' must be on sys.path at runtime for this to work. (e.g. by being the application script directory, by being on PYTHONPATH, or by being added to sys.path by your code.) """ I'll look into about adding a post-install report with this information for multi-version and alternate-directory installs. (That last paragraph above about '/your/instdir/setting' would only appear for --install-dir installs, and would include the actual directory name.)
Yeah, I really didn't want to make it possible to have 'SQLobject' and 'sqlobject' both exist as distributions (even though I believe PyPI currently allows that). It would be just too darn confusing to make a typo and end up with the entirely wrong product, once we have automatic package location via PyPI et al.

At 02:44 PM 5/30/2005 -0500, Ian Bicking wrote:
What do you mean by "this doesn't work"? Currently, the egg runtime never reads anything out of PKG-INFO except for the 'Version' field. So, although the 'Name' field reads "WSGI Utils", it is still recognized as the 'WSGI_Utils' package by 'require()'. What it *won't* be recognized as, is 'WSGI Utils', which is a requirement syntax error since package names in requirement specs can't have spaces in them. You're probably right, though, that the PKG-INFO file 'Name:' should match the actual egg name, so I've made that change and it should go out in 0.3a3. (The 'Name:' will read 'WSGI-Utils'). Note that egg names can currently only contain alphanumeric characters, '_', or '-'. And those last two are interchangeable, as '-' is converted to '_' in the egg's actual filename. Spaces in the setup(name="") argument are converted to '-'. It's possible that this range could/should be expanded somewhat, but it seemed prudent to be conservative initially, since it's easier to add capability than to take it away.
participants (2)
-
Ian Bicking
-
Phillip J. Eby