<p dir="ltr"><br>
On 1 Sep 2013 01:04, "Antoine Pitrou" <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:<br>
><br>
> Oscar Benjamin <oscar.j.benjamin <at> <a href="http://gmail.com">gmail.com</a>> writes:<br>
> ><br>
> > The difference between this<br>
> ><br>
> > # setup.py<br>
> > if sys.argv[1] == 'install':<br>
> > from myproj.build import build<br>
> > build()<br>
> ><br>
> > and something like this<br>
> ><br>
> > # setup.cfg<br>
> > [install]<br>
> > command = "from myproj.build import build; build()"<br>
><br>
> Well, sure, this is a rather silly way to use a ini-style declarative<br>
> format. I agree we wouldn't gain anything if setup.cfg files ended up<br>
> written like this.<br>
><br>
> > > I tend to disagree. Such bugs are not fixed, not because they shouldn't /<br>
> > > can't be fixed, but because distutils isn't really competently maintained<br>
> > > (or not maintained at all, actually; Éric sometimes replies on bug entries<br>
> > > but he doesn't commit anything these days).<br>
> ><br>
> > So is that particular issue a lost cause?<br>
><br>
> Why would it be?<br>
><br>
> > > The idea that "distutils shouldn't change" was more of a widely-promoted<br>
> > > propaganda item than a rational decision, IMO. Most setup scripts wouldn't<br>
> > > suffer from distutils changes or improvements; the few that *may* suffer<br>
> > > belong to large projects which probably have other items to solve when a<br>
> > > new Python comes out, anyway.<br>
> ><br>
> > It's not just the setup script for a particular project. It's the<br>
> > particular combination of compilers and setup.py invocations used by<br>
> > any given user for any given setup.py from each of the thousands of<br>
> > projects that do anything non-trivial in their setup.py.<br>
><br>
> I don't know what those "thousands of projects" are. Most Python projects<br>
> don't even need a compiler, except Python itself.<br>
><br>
> > For example<br>
> > in the issue I mentioned above the spanner in the works came from PJE<br>
> > who wanted to use --compiler=mingw32 while surreptitiously placing<br>
> > Cygwin's gcc on PATH:<br>
> > <a href="http://bugs.python.org/issue12641#msg161514">http://bugs.python.org/issue12641#msg161514</a><br>
> > It's hard for distutils to react to outside changes in e.g. external<br>
> > compilers because of the need to try and prevent breaking countless<br>
> > unknown and obscure setups for each end user.<br>
><br>
> This sounds like a deformation of reality. Most users don't have<br>
> "unknown and obscure setups", they actually have quite standardized<br>
> and well-known ones (think Windows, OS X, mainstream Linux distros).<br>
><br>
> Sure, in some communities (scientific programming, I suppose) there<br>
> may be obscure setups, but those communities have already grown their<br>
> own bag of tips and tricks, AFAIK.</p>
<p dir="ltr">This perception is just wrong. Mac OS X is a mess due to clang vs gcc vs homebrew vs macports vs Xcode, Windows is a mess due to mingw and cygwin and platform SDKs and visual studio (Express or otherwise). Linux distros are also ridiculous, with different gcc variants, library locations and various other things, depending on flavour and version.</p>
<p dir="ltr">distutils itself is nigh impossible to work on, since it is underspecified, and the fact it was added to the standard two years before unittest still shows in its test suite. (This lack of test coverage is also a large part of the reason setuptools *isn't* quite a drop-in replacement).</p>
<p dir="ltr">The key reason working on Python packaging has a tendency to chew developers up and spit them back out isn't because the people trying to work on it are incompetent, but because it's a genuinely hard problem where the already formidable technical issues are dwarfed by even more complex social ones. One of the most demotivating aspects comes from core developers without extensive experience of the existing packaging ecosystem failing to perceive the complexity of the problems to be addressed, and insulting the competence of the people working on packaging tools as a result. This is an aspect of the problem I was guilty of contributing to myself until a year or so ago, and after a change in role at Red Hat led to me learning the error of my ways, reducing it was one of my main motivations for cutting python-dev out of the approval process for the packaging related PEPs that don't immediately affect CPython or the standard library. </p>
<p dir="ltr">While pure Python distributions are common, there's an awful lot of "Python" code which includes C accelerator modules, wrappers around C or C++ libraries, including Cython or SWIG generated versions of both. This affects crypto, databases, networking, operating system interfaces, graphics and other domains that rely heavily on non-Python code, not just the scientific community.</p>
<p dir="ltr">setuptools definitely has its issues, but it's still substantially superior to distutils, and has the critical virtue of behaving the *same* in all currently supported versions of Python. Consistency across platform versions is something you really want in a build tool, and is something a standard library module like distutils can never provide. As one of the most conservative Linux vendors, even Red Hat has acknowledged this key point by creating the Red Hat Developer Toolset to provide a more consistent build experience across different RHEL versions. Microsoft (with Visual Studio) and Apple (with XCode) have long worked the same way.</p>
<p dir="ltr">Cheers,<br>
Nick.<br></p>
<p dir="ltr">><br>
> Regards<br>
><br>
> Antoine.<br>
><br>
><br>
> _______________________________________________<br>
> Distutils-SIG maillist - <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br>
> <a href="http://mail.python.org/mailman/listinfo/distutils-sig">http://mail.python.org/mailman/listinfo/distutils-sig</a><br>
</p>