Re: [Distutils] PEP 376 up-to-date
At 12:29 PM 5/25/2009 +0200, Tarek Ziadé wrote:
Hello,
I have updated PEP 376, mainly with Phillip's feedback, and changed the API section so it looks like the current prototype.
- PEP : http://svn.python.org/view/peps/trunk/pep-0376.txt?view=markup - prototype code : http://bitbucket.org/tarek/pep376/src/tip/pkgutil.py
I'll wait for a new round of feedbacks, Thanks !
* There's no reason for anything shown in the module to be private; is_egg_info() and egg_info_dirs() would be useful API functions, and the additions to DistributionMetadata might as well go in distutils * Better yet, move DistributionMetadata to pkgutil and have distutils.dist import it; that way you won't get tons of distutils.* imports any time you import pkgutil. * get_egg_infos() should take a pathlist argument, which if None can default to sys.path. * Project name normalization and case insensitive comparison is still not implemented * File path normalization (absolutizing, case-normalization, de-cross-platforming, etc.) is not implemented * There is extensive coupling both to sys.path and to the global cache; in particular, the owns() operation properly belongs to an object representing a *directory*, rather than an object representing an individual project. Note too that such "directory" objects would then also be an appropriate cache target, and a suitable home for egg_info_dirs() and get_file_users() operations. This also simplifies get_egg_infos, since it would simply either retrieves directories from the cache or creates them and optionally caches them, without also meddling in the details of cache contents. Also, an application that wishes to do so can simply create directory objects of its own and manage their lifecycle accordingly. Personally, I would also make an object for a collection of directories, but you could possibly get away without it. (At this point, I have only briefly skimmed the updated PEP; I'll take a closer look at it once the API/implementation gets more settled.)
2009/5/26 P.J. Eby
* There is extensive coupling both to sys.path and to the global cache; in particular, the owns() operation properly belongs to an object representing a *directory*, rather than an object representing an individual project.
Note too that such "directory" objects would then also be an appropriate cache target, and a suitable home for egg_info_dirs() and get_file_users() operations. This also simplifies get_egg_infos, since it would simply either retrieves directories from the cache or creates them and optionally caches them, without also meddling in the details of cache contents.
Also, an application that wishes to do so can simply create directory objects of its own and manage their lifecycle accordingly.
Personally, I would also make an object for a collection of directories, but you could possibly get away without it.
I can see the benefit of having such objects, I'll work on that. (and other points I didn't mention) Just one point though: - do we want to scan egg-info directories that are *directly* added in sys.path ? If we do so, using directories objects would require looking for the parent directory to create a directory object that hold each one of those "top" egg-info directories. This seems like a bad idea to me. Or maybe a specific global directory object could handle those top egg-info dirs. Its path would be virtual, and it would use "sys.path" instead of "os.listdir()" to list the elements it works it. Tarek -- Tarek Ziadé | http://ziade.org
I have reworked the APIs,
see http://bitbucket.org/tarek/pep376/src/tip/pkgutil.py
Now there's an EggInfoDirectory collection, that contains EggInfo
instances, and an EggInfoDirectories that contains EggInfoDirectory
instances.
While there's a global instance for the EggInfoDirectories class, it
doesn't load the sys.path implictely like setuptools does with its
master working set. This is done only if one of the global function is used.
One more thing:
2009/5/26 P.J. Eby
* Project name normalization and case insensitive comparison is still not implemented
* File path normalization (absolutizing, case-normalization, de-cross-platforming, etc.) is not implemented
The only thing done here is: - the egg_info_dirname APIs, which returns the egg-info directory name of a project. - the de-cross-platforming and absolutizing done in the EggInfo class when you use its methods I can see the need of more APIs in the egg_info and install_egg_info commands, but I don't see what else would be required in pkgutil
(At this point, I have only briefly skimmed the updated PEP; I'll take a closer look at it once the API/implementation gets more settled.)
ok then: I didn't update the PEP yet to reflect the code: I'll do it once we all find the API more settled Tarek
participants (2)
-
P.J. Eby -
Tarek Ziadé