On 13 September 2012 12:32, Tarek Ziadé
Here's my proposal - actually it's Nick's proposal but I want to make sure we're on the same page wrt steps, and I think that addresses Antoine concerns
1. create a new package, called pkglib (or whatever), located at hg .python.org as a new project that just strictly contains :
- the PEP implementations - non controversial features like files parser, pypi index browser etc
it's doable - since that's what we have done in distutils2. the modules that implements those PEPs are standalone
+1. I've seen far too many implementation of code that reads/writes RECORD files for instance. They are all subtly different and manage to have incompatible obscure bugs :-( A reference implementation would be an excellent thing. In the stdlib by preference, external for older versions is as good as you can get. The key here is to avoid having packaging tools with any more dependencies than necessary (because there's a bootstrapping issue with installing those dependencies...)
Let's avoid by all means to put the old distutils command logic there.
+1
Let's have a strict process on every new thing we're adding there.
Hmm. Agreed up to a point, but please let's not make it so hard to change things that are present that people go off and do their own thing again[1]. OTOH, I agree let's be cautious about adding new things. Once pkglib goes into the stdlib, that's when things get strict. Let's leave a bit of flexibility while the details are thrashed out.
2. make pkglib python 2 *and* python 3 compatible - natively, not w/ 2to3
+0
3. make distutils2, distribute, pip, bento, etc. use that and try to share as many bits as possible
We can't "make" anyone use pkglib, but if it clearly makes it easier to support the standards than implementing them yourself, it should persuade people. And we should certainly advocate supporting PEPs by using the reference implementation rather than reimplementing it yourself.
4. ask each project to pour in pkglib anything that can be reused by others
+1, although again it'll be down to the projects whether they do actually contribute. Also this somewhat contradicts the "be strict" point above, which is why I'm lukewarm on "be strict". Practicality vs purity - getting contributors/users is more important than insisting that everything be standardised before it can be implemented.
when 3.4 comes around, I guess we can decide if pkglib can go in or not.
I'd have an explicit goal to be included in 3.4 (so that people can imagine an end to the need for pkgutil being a dependency of their installation tool). But agreed it should not be assumed that this will happen if it's not ready (that was the mistake with packaging).
That way, we won't have the usual controversy about distutils' command machinery. People will use whatever tool and hopefully this tool will be based on pkgutil
+1. It also means that people will have a much greater incentive to support the new standards, because it should simply be a case of calling the pkglib implementation. Paul.