Packaging without setup.py/setuptools

[jayvdb]

setuptools is rarely needed, but it is nearly always used, creating an enormous risk of breakage for so many packages.

See https://stackoverflow.com/questions/25337706/setuptools-vs-distutils-why-is-distutils-still-a-thing

Installing without setup.py/setuptools wont be suitable for many projects repositories, but it will fill a niche that is increasingly being de-supported, which is whenever setuptools and friends no longer support a package, and embedded environments needing minimal size installs, and wanting to avoid setuptools/pip/etc which are quite large -- e.g. dockers where size does matter.

However the main one which I have recently been re-acquainted with is rpm builds, where the built package will be installed without setuptools, and currently setuptools is used as a build dependency only to generate the files needed.

For the vast majority of packages, setuptools could be replaced with a moban yaml file (maintained by the packager, outside the source repo) which defines the desired distro layout.

#64 is one setuptools-less installation method, using a toml file instead of a yaml file.

Quite often the additional steps performed in setup.py are not actually wanted by packagers, because they have their own way of providing dependencies, and different ways of creating and installing man pages, etc.

But if a packager does need additional steps done in setup.py, they could use pypi-mobans to generate a new setup.py which they control, using distutils (reduced risk), or even with setuptools which pypi-mobans already supports, so it only does the bits they want.

Some simple steps towards this would be to add fallbacks to distutils where possible.

[chfw]

This is a detailed explanation why distutils is seen in somesetup.py as a fallback.

[jayvdb]

An example of why packagers would benefit from being able to easily use a non-setup.py install , or overwrite setup.py with a simplified/maintained logic - thoughtnirvana/slimish-jinja2#4