[Python-Dev] packaging location ?

[Tarek Ziadé]

On 9/13/12 11:38 AM, Antoine Pitrou wrote:
> On Thu, 13 Sep 2012 11:14:17 +1000
> Nick Coghlan <ncoghlan at gmail.com> wrote:
>> On Thu, Sep 13, 2012 at 8:43 AM, R. David Murray <rdmurray at 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


>