PJ Eby <pje <at> telecommunity.com> writes: > 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.
I will give some thought to migration concerns. I'm not sure exactly what the best approach is, or if identical semantics are achievable in all areas. > 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.) I don't believe that wheels are meant to be directly importable, but I could be wrong about that. I am not sure why callee dependencies need to be transparently met by distributions not on sys.path; Broadly speaking, and leaving eggs out of the picture, I would expect a distribution to declare its dependencies, and for these to be installed in the appropriate site-packages by the installer. > Do you mean that it is not possible to identify the entry points of an > arbitrary distribution? What about obtaining information about the At the moment, not for a completely arbitrary distribution, as we don't have the metadata in non-installed distributions. Of course, an arbitrary distribution could be unpacked to a temporary location and have the equivalent of egg-info run to get the information; but for this to work ideally, such information would need to be present in the archive metadata and also need to be in the index. There are a number of ways this could happen - it's not clear to me what the best way is, but I probably haven't thought about it enough. > extras required by an entry point? (i.e., is it possible for someone > to make a common wrapper that re-adds sys.path management?) I think it's too early to say. > > 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. I assume from the context above that that you actually mean "no" as the answer to the question "is it insufficient?", whereas I would take "probably so" to mean "yes, it's insufficient". Regards, Vinay Sajip _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig