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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4