On Fri, Aug 30, 2013 at 7:18 PM, Antoine Pitrou <solip...@pitrou.net> wrote: > Nick Coghlan <ncoghlan <at> gmail.com> writes: >> >> On 30 Aug 2013 17:23, "Paul Moore" <p.f.moore <at> gmail.com> wrote: >> > >> > On 30 August 2013 00:08, Nick Coghlan <ncoghlan <at> gmail.com> wrote: >> >> >> >> We also need to officially bless pip's trick of forcing the use of > setuptools for distutils based setup.py files. >> > >> > >> > Do we? What does official blessing imply? We've managed for years > without the trick being "official"... >> > >> > The main reason it is currently used is to allow setup.py install to > specify --record, so that we can get the list of installed files. If > distutils added a --record flag, for example, I don't believe we'd need the > hack at all. (Obviously, we'd still need setuptools so we could use wheel to > build wheels, but that's somewhat different as it's a new feature). Maybe a > small distutils patch is better than blessing setuptools here? >> >> A distutils patch won't help with Python 2.7 or 3.3. The purpose of > blessing the substitution is to decouple the update cycle of the build > system from the update cycle of the standard library. > > It sounds like a nasty hack. What you call "substitution" is actually monkey > patching, > right? (edit: apparently it is pre-loading setuptools, which probably does > the monkey patching by itself) > > This is crazy. We removed packaging from the stdlib because it wasn't > "good enough", and now we would "bless the substitution" (aka silent runtime > monkeypatching) of distutils with setuptools, a third-party library whose > stdlib > inclusion has always been widely refused by the community (for many reasons)? > > pip can do what it likes, but blessing such behaviour officially sounds > completely > backwards. > > Regards > > Antoine.
One of the most important packaging insights to understand is that distutils is in fact worse than setuptools. It is badly outdated, poorly extensible, and too complex to ever re-implement in a compatible way. It is not better before the monkey patching. In a perfect world it should be removed from the standard library too except that removing distutils would be too impractical. The new strategy is to standardize just the install (how to install a wheel binary package after it has already been built) and runtime for eventual standard library inclusion. These are simple enough that they can be documented and re-implemented adequately. Distutils and setuptools will both be equally discouraged as legacy build tools. *Hopefully* a dominant 80% simpler-use-cases distutils replacement will emerge along with a more complicated 20% "scipy" distutils replacement but neither will necessarily need to be in the standard library; more complicated build+install tools that can deal with both sdists and wheels will be able to grab the necessary build tool as part of the build. If you can believe that distutils, not setuptools, is the problem we are trying to recover from, then the monkeypatching strategy may make more sense. We are also making setuptools optional *at run time* even for packages that need to be built under setuptools. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
