[Python-Dev] Status of packaging in 3.3

[Dag Sverre Seljebotn]

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 easy_install
>>> 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