On 9/13/12 11:38 AM, Antoine Pitrou wrote:
On Thu, 13 Sep 2012 11:14:17 +1000
Nick Coghlan <ncogh...@gmail.com> wrote:
On Thu, Sep 13, 2012 at 8:43 AM, R. David Murray <rdmur...@bitdance.com> wrote:
When the removal was being pondered, the possibility of keeping certain
bits that were more ready than others was discussed. Perhaps the best
way forward is to put it back in bits, with the most finished (and PEP
relevant) stuff going in first. That might also give non-packaging
people bite-sized-enough chunks to actually digest and help with.
This is the plan I'm going to propose. The previous approach was to
just throw the entirety of distutils2 in there, but there are some
hard questions that doesn't address, and some use cases it doesn't
handle. So, rather than importing it wholesale and making the stdlib
the upstream for distutils2, I believe it makes more sense for
distutils2 to remain an independent project, and we cherry pick bits
and pieces for the standard library's new packaging module as they
stabilise.
How is that going to be useful? Most people use distutils / packaging as
an application, not a library. If you provide only a subset of
the necessary features, people won't use packaging.
Regards
Antoine.
Yeah but we've been too ambitious.
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
Let's avoid by all means to put the old distutils command logic there.
Let's have a strict process on every new thing we're adding there.
2. make pkglib python 2 *and* python 3 compatible - natively, not w/ 2to3
3. make distutils2, distribute, pip, bento, etc. use that and try to
share as many bits as possible
4. ask each project to pour in pkglib anything that can be reused by others
when 3.4 comes around, I guess we can decide if pkglib can go in or not.
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
_______________________________________________
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
