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