On 17/03/2008, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > That leaves MAL, whose objections to PEP 365 centered on the API (he > said he was "+1 on the concepts being added to the stdlib, -1 on > adding the module in its current state"). Among other concerns, he > wanted pkg_resources to be split into pkgutil and a new "egglib" > module. I don't have a problem with this in principle, if there were > a pkg_resources module that reconstituted the merged API. (But there > are some practical problems with that approach, such as trying to > split namespace package support between two theoretically-unrelated modules.)
I would personally like to see such a separation. As one of the authors of PEP 302 (well, the documentation - Just did all of the implementation) I have an interest in strengthening the standard library's support for transparent use of PEP 302 importers. To that end, I would like to see such functions as pkg_resources.resource_string() standardised. That covers the pkgutil aspect of pkg_resources. The "egglib" side of things is where the controversy lies, IMHO. I have a (somewhat unfocussed) dislike of eggs, largely because of the lack of a package management tool to handle them. I can live with them or without them, and it doesn't bother me if others use them, but the thing that really, really bothers me is that the controversy (and yes, there is such) over eggs is hampering the adoption of the pkgutil side of pkg_resources. So from me, there's a strong +1 for the split of pkg_resources into additions to the existing pkgutil module, and an independent egglib. You say there are practical problems to doing this. OK, but could we not have a discussion on how to resolve those issues as they come up? Could the split not be initially into 3 parts - pkgutil (eg, resource_string), egglib, and "difficult"? Then there would be something concrete to discuss and resolve. Paul. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
