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
