On 21 October 2015 at 19:32, David Cournapeau <courn...@gmail.com> wrote: > > > On Wed, Oct 21, 2015 at 6:03 PM, Ronny Pfannschmidt > <opensou...@ronnypfannschmidt.de> wrote: >> >> why does that have to be in setuptools ?! >> >> if we want a new light system to begin with, shouldn't it be far more >> sustainable to use just implementations of the new standards rather than >> leaving all of setuptools >> >> there is no viable way in setuptools to get rid of the legacy ina sane and >> fast manner, it would drag out over years > > agreed. I have never met a person who had to deal substantially with > distutils code and enjoyed the experience. > > The whole architecture is fundamentally flawed. I wrote this a long time > ago, but I still stand by most arguments: > https://cournape.wordpress.com/2009/04/01/python-packaging-a-few-observations-cabal-for-a-solution/
It's also worth reading Greg Ward's post on how distutils came to be: http://gerg.ca/blog/post/2013/distutils-history/ Something else not a lot of folks realise is that setuptools was originally built to handle development for the Open Source Application Foundation's Chandler project: https://en.wikipedia.org/wiki/Chandler_%28software%29 Neither setuptools nor distutils has particularly robust test suties, and nor do they have nicely structured public APIs, so refactoring either of them heavily is almost guaranteed to break something. OSAF's and Chandler's original needs are also far removed from the way we're using setuptools today (although the greatest of the differences relate to the differences between pip and easy_install moreso than anything on the build side). Despite those limitations, tens of thousands of software projects have been successfully published with both of them, so anyone trying to push for improvements needs to account for the popularity of pkg_resources for plugin management, the widespread use of setuptools based executable script wrappers, and the intertwined combination of distutils and setuptools that needs to be managed in order to successfully rebuild the whole of PyPI from source. Cheers, Nick. P.S. Anyone that decides to work on improving the packaging ecosystem also needs to account for the fact that they will hear relatively frequent complaints from *everybody*, as newcomers will complain "Why isn't it fixed yet?", veterans will complain "What have you broken today?", but almost nobody will offer to actually pay anyone to fix anything other than their own specific corner case, rather than investing in properly overhauling the entire system (which is as formidable a political challenge as it as a technical one). The core problem is that the status quo is merely clumsy and inelegant, rather than completely unusable. For all their flaws, both hobbyists and professional developers *can* use the current tools to distribute software (and they're still easier to deal with than writing directly for the native installer toolsets on each target platform), while in any organisation that uses Python heavily, setup scripts for new projects are likely to be either generated from templates or copied from those for old projects, rather than needing to be written from scratch each time. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
