On Tue, Oct 9, 2012 at 5:45 PM, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote: > Clearly, distlib can't do things exactly > the way they're done in pkg_resources and setuptools, since those are not > considered suitable to go into the stdlib,
The two aren't 100% connected, even assuming the antecedent were true. Originally, Guido Pronounced that they *were* to be added to the stdlib (for Python 2.5), and I withdrew them due largely to an objection about the lack of third-party expertise in the underlying formats -- an expertise that is now considerably more widespread, especially thanks to you and Daniel. ;-) More to the point, though, if it's not possible for someone to create a wrapper to reimplement these portions of the pkg_resources API, then it's going to be harder to get people to port their code. The challenge isn't necessarily that there are dozens of platforms that rely on this feature explicitly; the challenge is that code which uses pkg_resources APIs for these things is *intentionally ignorant* of whether the feature is being used. The entire point of the API is to free the caller from worrying about the callee's needs, and the callee's dependencies can be transparently met by distributions that are not directly on sys.path, at least in the .egg or .wheel model of things. (If .wheel files are importable, anyway.) > ISTM that the "exports" feature in distlib allows applications to cooperate in > the same way as pkg_resources' entry points do, except for the fact that > sys.path is not manipulated at all, meaning that all such cooperating > applications are assumed to be installed on the path. Do you mean that it is not possible to identify the entry points of an arbitrary distribution? What about obtaining information about the extras required by an entry point? (i.e., is it possible for someone to make a common wrapper that re-adds sys.path management?) > Actual importing is > delayed until needed; scanning of distribution metadata for exports also > happens on demand. Do you feel that this is insufficient to meet the > performance concerns you mentioned? Now that 3.3 includes a faster import mechanism, probably so. Under older Pythons, adding a large number of directories to sys.path could badly affect startup performance, if plugins were installed as directories instead of as zipfiles. (As a general note, in case you aren't aware: the entire .egg format was invented originally as a distribution+use format for application plugins; Bob Ippolito suggested that in the general case, any Python library could also be considered a "plugin" to Python itself, and then things kind of took off from there...) _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
