Daniel Holth <dholth <at> gmail.com> writes: > I feel it is necessary to implement pkg_resources.py on top of any new > API. For example just monkey-patch pkg_resources with the parts you've > implemented, or implement the new API by calling pkg_resources. It > would be a very healthy exercise to see whether you've forgotten > something, and avoids having to port 2/3rds of the software on pypi to > use the new API.
That can be looked at in due course. However, weaning projects off distutils/ setuptools APIs and onto anything else will not be pain-free. ISTM one can't promise to fulfil the contract of the pkg_resources resource functions, without essentially duplicating large chunks of pkg_resources; for example, the resource functions take a Requirement object as well as a package name, so any usage of the APIs with Requirements would not work with a simple wrapper. There are specific functions in pkg_resources which I have specifically left out: for example, there's no "get a real filename for this resource, extracting it from zip to a cache folder if you need to". This type of functionality doesn't seem to be a core requirement and could be provided with a specialised finder if really needed, but I see no case for it in the base classes which might go in the stdlib. The resources API is IMO small and simple enough to evaluate on its own (in terms of whether it meets the stated requirements, and whether the stated requirements are complete). PEP 365, proposing inclusion of pkg_resources in the stdlib, was rejected. It doesn't seem right to have something which might potentially be in the stdlib monkey-patching external projects. There might be other approaches to ease porting to new APIs, e.g. 2to3 style fixers. > Does pkgutil's resource API (get_data) fit in in any way? I notice it > includes the "list zip contents" implementation but it doesn't expose > it in any way. It would be a chore to have to implement 3 importer > adapters to make all 3 APIs work. I'm not sure I quite understand what you mean, as I couldn't see any reference to listing zip contents in the pkgutil docs, but pkgutil's get_data wraps the PEP 302 loader's get_data API, as does distlib.resources. However, pkgutil.get_data doesn't allow you to customise its behaviour, whereas distlib.resources does (by allowing you to implement and register your own finder). One of the reasons why Python packaging is in its current state is that distutils is hard to extend. Any replacement APIs we introduce should not repeat that mistake. While pkg_resources is not quite so bad in that department, since it allows for providers for different loaders, its provider hierarchy seems to be such that eggs are an integral part of the mix, rather than an option you can do without: IResourceProvider NullProvider EmptyProvider EggProvider DefaultProvider ZipProvider In distlib.resources, there are only three equivalents: Resource -> IResourceProvider ResourceFinder -> DefaultProvider ZipResourceFinder -> ZipProvider Part of the feedback I'm looking for is whether these provide a suitable basis for extending by packaging tool providers where needed. Regards, Vinay Sajip _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig