On 19 March 2015 at 02:49, Paul Moore <[email protected]> wrote: > On 18 March 2015 at 16:02, Ionel Cristian Mărieș <[email protected]> wrote: >> one certainly doesn't need to shoehorn a full blown build system into >> setup.py - there's make, invoke, shell scripts and plenty of other systems >> that can do that just fine. > > Just to insert a little history here, before distutils (setup.py) was > invented, Python packages used all sorts of tools to build. Often > shell scripts and/or make were used, which in essence meant that the > packages were unusable on Windows - even if there was no need for them > to be. > > Distutils may be bad, but it's still far better than what it replaced :-)
Aye, without distutils there's no fpm, pyp2rpm, etc. At least Fedora has migrated its packaging policy from invoking setup.py directly to invoking it via pip instead, but that wouldn't be possible without the commitment to make sure that everything that builds today keeps building tomorrow. What's changed in the 16-17 years since distutils was first designed is the rise of open source usage on Windows and Mac OS X clients, together with the desire for development and data analysis focused user level package management on Linux (which major Linux distros currently tend not to provide, although some of us would like to if we can come up with a reasonable approach that keeps the long term sustaining engineering costs under control [1]). The "simpler" packaging systems like npm, etc get to be simpler because they're written for specific problem domains (e.g. public cloud hosted web service development for npm), so it's much easier to cover all the relevant use cases. With setuptools/distutils the use cases are just as sprawling as the use cases for Python itself, so we're trying to cover needs that range from kids tinkering on their Raspberry Pi's, to multinationals operating public cloud infrastructure, to folks writing web services, to scientists doing computational research, to financial analysts, to spooks on air-gapped networks, to industrial control systems, etc, etc, etc. Solving the software distribution problems of any *one* niche is hard enough that you can build large profitable ecosystems on the back of them (this is why platform specific app stores are so popular), but that's a relatively simple and straightforward problem compared to figuring out how to build the backbone infrastructure that lets open source developers learn one set of software distribution tooling themselves, while still being to relatively easily feed into all of the other downstream systems :) Cheers, Nick. [1] https://fedoraproject.org/wiki/Env_and_Stacks/Projects/UserLevelPackageManagement -- Nick Coghlan | [email protected] | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
