[Distutils] Time for a setuptools_lite??

[Nick Coghlan]

On 21 October 2015 at 19:32, David Cournapeau <cournape at gmail.com> wrote:
>
>
> On Wed, Oct 21, 2015 at 6:03 PM, Ronny Pfannschmidt
> <opensource at 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   |   ncoghlan at gmail.com   |   Brisbane, Australia