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

Dag Sverre Seljebotn d.s.seljebotn at astro.uio.no
Thu Jun 21 11:08:33 CEST 2012

On 06/21/2012 05:57 AM, Nick Coghlan wrote:

On Thu, Jun 21, 2012 at 3:29 AM, PJ Eby<pje at telecommunity.com> wrote:

On Wed, Jun 20, 2012 at 9:02 AM, Nick Coghlan<ncoghlan at gmail.com> wrote:

On Wed, Jun 20, 2012 at 9:46 PM, Antoine Pitrou<solipsis at pitrou.net> wrote: Agreed, especially if the "proven in the wild" criterion is required (people won't rush to another third-party distutils replacement, IMHO). The existence of setuptools means that "proven in the wild" is never going to fly - a whole lot of people use setuptools and easyinstall happily, because they just don't care about the downsides it has in terms of loss of control of a system configuration. Um, this may be a smidge off topic, but what "loss of control" are we talking about here? AFAIK, there isn't anything it does that you can't override with command line options or the config file. (In most cases, standard distutils options or config files.) Do you just mean that most people use the defaults and don't care about there being other options? And if that's the case, which other options are you referring to? No, I mean there are design choices in setuptools that explain why many people don't like it and are irritated when software they want to use depends on it without a good reason. Clearly articulating the reasons that "just include setuptools" is no longer being considered as an option should be one of the goals of any PEPs associated with adding packaging back for 3.4. The reasons I'm personally aware of: - it's a unilateral runtime fork of the standard library that bears a lot of responsibility for the ongoing feature freeze in distutils. Standard assumptions about the behaviour of site and distutils cease to be valid once setuptools is installed - overuse of "*.pth" files and the associated sys.path changes for all Python programs running on a system. setuptools gleefully encourages the inclusion of non-trivial code snippets in *.pth files that will be executed by all programs. - advocacy for the "egg" format and the associated sys.path changes that result for all Python programs running on a system - too much magic that is enabled by default and is hard to switch off (e.g. http://rhodesmill.org/brandon/2009/eby-magic/) System administrators (and developers that think like system administrators when it comes to configuration management) hate what setuptools (and setuptools based installers) can do to their systems. It doesn't matter that package developers don't have to do those things - what matters is that the needs and concerns of system administrators simply don't appear to have been anywhere on the radar when setuptools was being designed. (If those concerns actually were taken into account at some point, it's sure hard to tell from the end result and the choices of default behaviour)

David Cournapeau's Bento project takes the opposite approach, everything is explicit and without any magic.

http://cournape.github.com/Bento/

It had its 0.1.0 release a week ago.

Please, I don't want to reopen any discussions about Bento here -- distutils2 vs. Bento discussions have been less than constructive in the past -- I just wanted to make sure everybody is aware that distutils2 isn't the only horse in this race. I don't know if there are others too?

-- Dag Sverre Seljebotn

More information about the Python-Dev mailing list