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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4