[Python-Dev] Status of packaging in 3.3

[Vinay Sajip]

Chris McDonough <chrism <at> plope.com> writes:

> On 06/21/2012 04:45 AM, Nick Coghlan wrote:
> > A packaging PEP needs to explain:
> > - what needs to be done to eliminate any need for monkeypatching
> > - what's involved in making sure that *.pth are *not* needed by default
> > - making sure that executable code in implicitly loaded *.pth files
> > isn't used *at all*
> 
> I'll note that these goals are completely sideways to any actual 
> functional goal.  It'd be a shame to have monkeypatching going on, but 
> the other stuff I don't think are reasonable goals.  Instead they 
> represent fears, and those fears just need to be managed.

Managed how? Whose functional goals? It's good to have something that works here
and now, but surely there's more to it. Presumably distutils worked for some
value of "worked" up until the point where it didn't, and setuptools needed to
improve on it. Oscar's example shows how setuptools is broken for some use
cases. Nor does it consider, for example, the goals of OS distro packagers in
the same way that packaging has tried to. You're encouraging core devs to use
setuptools, but as most seem to agree that distutils is (quick-)sand and
setuptools is built on sand, it's hard to see setuptools as anything other than
a stopgap, the best we have until something better can be devised.

The command-class based design of distutils and hence setuptools doesn't seem to
be something to bet the future on. As an infrastructure concern, this area of
functionality definitely needs to be supported in the stdlib, even if it's a
painful process getting there. The barriers seem more social than technical, but
hopefully the divide-and-conquer-with-multiple-PEPs approach will prevail.

Regards,

Vinay Sajip