Lack of --root option, broken setup.py makes flit unusable for creating Void, Arch and Alpine Linux system packages

[ahesford]

As described in pypa/packaging#363, the packaging systems of Void, Arch and Alpine Linux (as well as others, I'm sure) rely on the ability to install software to otherwise empty destination directories that are used to define the contents of distribution packages. For Python packages using setuptools or distutils, this is accomplished by providing a --root argument to setup.py.

flit provides no comparable mechanism, instead allowing installation only into a per-user environment, the system environment or a virtual environment by passing the path to the python executable within that environment. The only possible workaround to this limitation is populating a destination directory with a virtual environment, using flit install to install to that environment, and then removing all parts of the virtual environment except the specific Python package to be wrapped in a distribution package. Obviously, this is not a viable solution.

The flit build or flit publish commands provide a partial workaround, because they produce source tarballs with a basic setup.py. However, the flit project discourages reliance on these scripts, even explicitly breaking them by importing distutils.core.setup rather than setuptools.setup despite their reliance on setuptools-specific keywords like install_requires, python_requires and extras_require. An attempt to prefer setuptools was explicitly rejected in #333. Reliance on pip to do the right thing isn't generally appropriate; especially for distribution packaging, using pip is a recipe for disaster because it deprives the packager of a lot of control (or at least makes the build process more difficult to manage).

If flit is to be usable by distribution packaging systems, then a couple of enhancements should be considered:

1. Reconsider Generated setup.py use setuptools when available #333, allowing flit to produce a setup.py that works properly with setuptools, so projects can still provide source tarballs that are properly buildable and relocatable without flit.
2. Support a --root argument in flit to allow installation with respect to an arbitrary (and most likely empty) $DESTDIR.

The first option seems to be low-hanging fruit (particularly since the work is done). The second option may be complicated if flit seeks eventually to support more advanced build procedures. For example, if flit intends to support compiled extensions in CPython, the compilation environment should be easily controllable because packaging systems like Void's xbps-src are designed to compile or cross compile for several different architectures.

[takluyver]

Oh what joy for a Sunday morning.

The flit command line interface is meant for people working on packages. The canonical way to install an arbitrary Python package from source is to make a wheel (with standard APIs specified in PEP 517), and then install the wheel, which is a documented format. pip can be used for that, and there's lower-level tooling in development in the pypa-build project and @pradyunsg's WIP installer project. flit install already generates a wheel and then calls pip to install it, so you're not doing anything more low-level by running that.

[ahesford]

Thanks for clarifying the scope of flit.