User experience with porting off

An interesting question in the blog post is

I don’t know basic things like whether my adoption of pyproject.toml will break end-users stuck on older Python versions or what.

(The experts might prove me wrong.)

As far as I know, as long as you upload wheels to PyPI, pip install will keep working whatever the Pip version, because Pip prefers downloading a wheel from PyPI and installing it over downloading an sdist and building it into a wheel locally. (The wheel format dates back to 2012 so it would be hard to find a Pip that doesn’t support it.)

If you remove the entirely, then things might break for people who do wget https://your-project-source/tarball.tar.gz; tar -xvf tarball.tar.gz; cd tarball; python install or such in scripts. Not much can be done about that. One public of people who build from source is package maintainers (Linux distros, Homebrew, etc.). Since pyproject.toml-based builds are the standard today, they’ll just have to update the package definition, which should be routine.

(Me thinks this could be mentioned in the packaging guide somewhere…)


I still haven’t ported my project metadata from to pyproject.toml because I don’t understand the implications.

There is little in terms of implications. The metadata ends up represented in the same way in the wheel.

The only downside I can think of is that it might break the deprecated python install for people with old setuptools versions that won’t understand pyproject.toml metadata.

One reason to prefer declarative metadata is that there can be tools to interact with it (like auto-bumping dependencies, as I mentioned above).

1 Like