Switch to flit

[layday]

After #393, our two remaining required dependencies will both be using flit as their build backend. Switching to flit would eliminate two build dependencies (setuptools and wheel) and will simplify bootstrapping build without setuptools. Flit is also able to generate a setup.py from its metadata which we can version for setuptools holdouts.

[takluyver]

To be transparent, I'm planning for Flit to move away from generating setup.py. It might be a while before the ability is actually removed, but I'm thinking of disabling it by default in the next release. So don't rely on that in the longer term. However, it shouldn't be much effort to maintain a minimal setup.py - just enough to get the package installed - by hand if you feel that's necessary.

[henryiii]

The wheels still work, so I'd not worry about legacy setup.py's too much. Guessing a few distro packaging systems might like it, but other than that, it's probably not useful.

[layday]

We should not remove setup.py at least not before installer has a CLI.

[henryiii]

https://pypi.org/project/installer/, I assume. Designed to allow distributions and such to use pure-python wheels instead of SDists?

[layday]

The point is that the only other way to install a wheel is by using pip which a lot of distros cannot stomach. installer is meant to provide a lightweight alternative to that. Up till now, the most common way to bootstrap Python is using setuptools, and relying on foundational dependencies to be setup.py-installable.

[astrojuanlu]

at least not before installer has a CLI

xref https://github.com/pradyunsg/installer/issues/52

[pradyunsg]

With installer getting a CLI (https://installer.readthedocs.io/en/latest/cli/installer/) and flit_core getting better bootstrapping story pretty soon (pypa/flit#511), I think this is now unblocked for moving to flit.

I think migrating to flit would also bring a fairly clean boostrapping story as well.

• Build and install flit_core, through flit_core's boostrappers.
• Build installer with flit_core, and install with flit_core's bootstrapper.
• Build build with flit_core, and install with installer.
• You have build and installer installed, and ready for use.
• python -m build . && python -m installer ./dist/*.whl will install the project in cwd into the running Python version.

[takluyver]

Build installer with flit_core, and install with flit_core's bootstrapper.

And install with installer itself (running from source)? At least, this is my assumption for how it should work. The bootstrap_install.py script for flit_core is only meant to be for installing flit_core itself, and currently it checks that the filename starts with flit_core-.

There are a few more intermediate steps for build's dependencies - packaging, tomli and pep517 (/your pyproject-hooks fork) - but if packaging switches to Flit again as I think was planned, then they can all be built with flit_core and installed with installer, so there's no extra complexity there, just doing the same thing a couple more times.

Other than that, 👍

[vishwin]

flit_core is absolutely self-bootstrapping now. installer installs itself after flit_core generates the wheel in installer's working copy.

if packaging switches to Flit again as I think was planned, then they can all be built with flit_core and installed with installer,

I've nudged at pypa/packaging#340.

[nanonyme]

Packaging has now switched to flit. No release done though. pyparsing dependency from packaging is gone.

[nanonyme]

@pradyunsg how we ended doing bootstrapping is we (with PYTHONPATH) use installer to install wheel of itself. It works fine. Then we don't need to use flit_core bootstrap install to install anything else than flit_core. (I think it doesn't even support by design anything else)