[Python-Dev] Status of packaging in 3.3

[Antoine Pitrou]

On Wed, 20 Jun 2012 12:11:03 +0100
Paul Moore <p.f.moore at 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.