On Fri, May 15, 2009 at 10:48 AM, P.J. Eby wrote:

At 11:38 PM 5/14/2009 +0200, Tarek Ziadé wrote:

...

That happened because I got a bit lost in the way finders were working in setuptools, which seemed a bit over-engineered at that time to me (but I might end up changing my mind at sime point when I understand it better).

The finders mechanism is there to allow support for arbitrary PEP 302 importers -- i.e., sys.path strings that don't go to the filesystem.

The main reason why there are two finders currently (find_on_path and find_in_zip) is that find_in_zip supports egg directory bundling. That is, an .egg zipfile may contain arbitrarily nested .egg directories, and an .egg directory may contain arbitrarily nested .egg directories or .egg zipfiles.

The idea of nested eggs reminds me again of the concept of a "toolset", where something like virtualenv contains a discreet set of libraries for a particular package, like Pylons 0.9.7. You could download this qualified toolset without needing to worry about runtime configuration issues, and then it would also be quite fast to import if it was isolated from the other toolsets. This means that an entry point could just call right to a toolset or a set of toolsets. The downside of having isolated toolsets/virtualenvs is more diskspace, and the need to explicately add new libraries to your toolset. The upside is a streamlined sys.path and guaranteed compatability by the toolset authors.

However, if you're not implementing dependency resolution, you don't need that support. If such a nested item were in use, it'd be on sys.path already. (In other words, the nesting lookups are only useful for alternate version discovery, not simple metadata lookups.)

_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig

-- Cheers, Noah