On 31 August 2013 14:24, Antoine Pitrou <solip...@pitrou.net> wrote: > Oscar Benjamin <oscar.j.benjamin <at> gmail.com> writes: >> >> It will always be possible to ship a setup.py script that can >> build/install from an sdist or VCS checkout. The issue is about how to >> produce an sdist with a setup.py that is guaranteed to work with past, >> current, and future versions of distutils/pip/setuptools/some other >> installer so that you can upload it to PyPI and people can run 'pip >> install myproj'. It shouldn't be necessary for the package author to >> use distutils/setuptools in their setup.py just because the user wants >> to install with pip/setuptools or vice-versa. > > Agreed... But then, deprecating setup.py in favour of setup.cfg is a > more promising path for cross-tool compatibility, than trying to promote > one tool over another.
The difference between this # setup.py if sys.argv[1] == 'install': from myproj.build import build build() and something like this # setup.cfg [install] command = "from myproj.build import build; build()" is that one works now for all relevant Python versions and the other does not. With the setup.cfg end users cannot simply do 'python setup.py install' unless they have some additional library that can understand the setup.cfg. Even if future Python versions gain a new stdlib module/script for this current versions won't have it. That is why I agree with Nick that the best thing to do is to explicitly document what is *currently* required to make things work and guarantee that it will continue to work for the foreseeable future. Then alternative better ways to specify the build commands in future can be considered as hinted in the PEP: http://www.python.org/dev/peps/pep-0426/#metabuild-system >> Distutils is tied down with backward compatibility because of the >> number of projects that would break if it changed. Even obvious >> breakage like http://bugs.python.org/issue12641 goes unfixed for years >> because of worries that fixing it for 10000 users would break some >> obscure setup for 100 users (no matter how broken that other setup >> might otherwise be). > > I tend to disagree. Such bugs are not fixed, not because they shouldn't / > can't be fixed, but because distutils isn't really competently maintained > (or not maintained at all, actually; Éric sometimes replies on bug entries > but he doesn't commit anything these days). So is that particular issue a lost cause? > The idea that "distutils shouldn't change" was more of a widely-promoted > propaganda item than a rational decision, IMO. Most setup scripts wouldn't > suffer from distutils changes or improvements; the few that *may* suffer > belong to large projects which probably have other items to solve when a > new Python comes out, anyway. It's not just the setup script for a particular project. It's the particular combination of compilers and setup.py invocations used by any given user for any given setup.py from each of the thousands of projects that do anything non-trivial in their setup.py. For example in the issue I mentioned above the spanner in the works came from PJE who wanted to use --compiler=mingw32 while surreptitiously placing Cygwin's gcc on PATH: http://bugs.python.org/issue12641#msg161514 It's hard for distutils to react to outside changes in e.g. external compilers because of the need to try and prevent breaking countless unknown and obscure setups for each end user. Although in that particular issue I think it's really just a responsibility thing: the current breakage can be viewed as externally caused. Fixing it trades a large amount of breakage that is gcc's fault for a small amount of breakage that would be Python's fault. Oscar _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig