On Wed, 20 Jun 2012 12:11:03 +0100 Paul Moore <p.f.mo...@gmail.com> wrote: > > I think the first question is, do we need an enhanced distutils in the > stdlib?
I would answer a different question: we definitely need a better distutils/packaging story. Whether it's in the form of distutils enhancements, or another package, is not clear-cut. By the way, let me point out that the "distutils freeze" has been broken to implement PEP 405 (I approve the breakage myself): http://hg.python.org/cpython/rev/294f8aeb4d4b#l4.1 > As far as I can see, this one has been answered strongly, in > the affirmative, a few times now. And yet, the need seems to be a > diffuse thing, with no real champion Packaging is not a very motivating topic for many developers (myself included). It's like the build process or the buildbot fleet :-) > 2. Free up distutils2 to develop as an external package, and then have > a PEP proposing its inclusion in the stdlib in due course, when it is > ready and has been proven in the wild. [...] > The downside is that the timescales would be a lot > longer (I doubt we'd see anything in 3.4 this way, and maybe not even > 3.5). Agreed, especially if the "proven in the wild" criterion is required (people won't rush to another third-party distutils replacement, IMHO). > 3. Write a PEP describing precisely what the packaging module will do, > get consensus/agreement, and then restart development based on a solid > scope and spec. I think it's the best way to sink the project definitively. Our community isn't organized for such huge monolithic undertakings. > [1] That reads really harshly. I don't mean to criticise any of the > work that's been done, I'm a huge fan of the idea of packaging, and > its goals. The "experiment" in this case is around process - > developing something as big and important as packaging with limited > developer resource, relatively directly in the core (bringing it in > from distutils2 sooner rather than later) and working from a series of > smaller PEPs focused on particular details, rather than an overall one > covering the whole package. I cannot speak for Tarek, but one of the reasons it's been done as a set of smaller PEPs is that these PEPs were meant to be included in *distutils*, not distutils2. That is, the module already existed and the PEPs were individual, incremental improvements. Regards Antoine. _______________________________________________ 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