On 06/21/2012 05:57 AM, Nick Coghlan wrote:
On Thu, Jun 21, 2012 at 3:29 AM, PJ Eby<p...@telecommunity.com> wrote:
On Wed, Jun 20, 2012 at 9:02 AM, Nick Coghlan<ncogh...@gmail.com> wrote:
On Wed, Jun 20, 2012 at 9:46 PM, Antoine Pitrou<solip...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
