On 31 August 2013 12:03, Antoine Pitrou <[email protected]> wrote: > Donald Stufft <donald <at> stufft.io> writes: >> > >> > The sticking point is that you don't *have* to install something >> > third-party >> > to get yourself working on some packaging. Being able to benefit from >> > additional features *if* you install something else is of course fine. >> >> Out of the four you listed I'm most familiar with Django's packaging which >> has gone to significant effort *not* to require setuptools. Most packages >> aren't willing to go through that effort and either simply require setuptools >> or they include a distutils fallback which often times doesn't work correctly >> except in simple cases*. >> >> * Not that it couldn't work correctly just they don't use it so they never > personally >> experience any brokenness and most people do not directly execute setup.py >> so the installers tend to handle the differences/brokenness for them. > > Executing setup.py directly is very convenient when working with a > development or > custom build of Python, rather than install the additional "build tools" > (which > may have their own compatibility issues). > For example I can easily install Tornado with Python 3.4 that way. > > I'm not saying most people will use setup.py directly, but there are > situations > where it's good to do so, especially for software authors.
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. 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). That kind of breakage is totally unacceptable to projects like numpy which is why they fixed the same bug in their own distutils extension 3 years ago. I claim that the only reason projects like numpy still use (extensions and monkey-patches of) distutils for building is that there is no documented way for them to distribute sdists that build using anything other than distutils. Bento tries to implement its own setup.py and when I try to install it with pip I find a bug in pip from code paths that wouldn't get hit if bento were using setuptools in their own setup.py. If it weren't for that bug and the output had instead been: $ pip install bento Downloading/unpacking bento Downloading bento-0.1.1.tar.gz (582kB): 582kB downloaded Running setup.py egg_info for package bento Installing collected packages: bento Running setup.py install for bento Error: Could not find .egg-info directory in install record for bento then we could argue about which of pip or bento was in contravention of the (non-existent) specification that defines the setup.py interface. Oscar _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
