[Python-Dev] packaging location ?

[Erik Bray]

On Thu, Sep 13, 2012 at 5:38 AM, Antoine Pitrou <solipsis at pitrou.net> 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.

Third-party install/packing software (pip, bento, even distribute) can
still gradually absorb any standard pieces added to the stdlib for
better interoperability and PEP compliance.  I'm still strongly in
favor of a `pysetup` like command making it into Python too, but in
the meantime the top priority should be anything that supports better
consistency across existing projects.