[Python-Dev] Status of packaging in 3.3 (original) (raw)

Vinay Sajip vinay_sajip at yahoo.co.uk
Thu Jun 21 15:45:16 CEST 2012

Chris McDonough <chrism 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

More information about the Python-Dev mailing list