[Distutils] setup_requires for dev environments

[Nick Coghlan]

On 19 March 2015 at 02:49, Paul Moore <p.f.moore at gmail.com> wrote:
> On 18 March 2015 at 16:02, Ionel Cristian Mărieș <contact at ionelmc.ro> 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   |   ncoghlan at gmail.com   |   Brisbane, Australia