Increase the version upper limit for flit_core to 5

[dvzrv]

Downstreams that attempt to build with latest flit_core (4.0.0) will not be able to (this is currently blocking us on Arch Linux to build/rebuild this project as a package).

In addition, an upper version limit does not seem to be very useful when it comes to the build backend.

[carltongibson]

... will not be able to (this is currently blocking us on Arch Linux to build/rebuild this project as a package

Can you explain that please?

I thought the whole point of the build backend system was that you can use any frontend against any backend, and the frontend will use the specified backend to build in an isolated environment. (So e.g. flit can build setuptools projects, and so on.)

The flit does say "...and can simply change the flit_core <4 constraint to <5."

[dvzrv]

Can you explain that please?

Well, as we now have flit_core 4.0.0, we cannot build this project, without modifying this pyproject.toml file.

I thought the whole point of the build backend system was that you can use any frontend against any backend, and the frontend will use the specified backend to build in an isolated environment. (So e.g. flit can build setuptools projects, and so on.)

We are only relying on the backends here and the bare minimum to build: build, installer, flit_core
If flit_core does not match the limits you are setting here, then a downstream cannot build this project.

The flit does say "...and can simply change the flit_core <4 constraint to <5."

If you'd rather still see an upper limit, let me know.
It's just that we will likely have to remove them again in the future and depending on how many projects are affected, this will be quite the chore 😅

[carltongibson]

We are only relying on the backends here and the bare minimum to build: build, installer, flit_core
If flit_core does not match the limits you are setting here, then a downstream cannot build this project.

I'm still not following you, sorry.

You do, maybe?:

$ python -m build 

Build will create an isolated environment using the backend specified by the project. This is the whole point of PEP 517 &co, no? 🤔

Given flit v4 exists, making an adjustment here looks fine, but I need to grasp why what's there is broken vs (merely) using the older version for the build?

If you'd rather still see an upper limit...

I'd rather follow the documented advice.

[dvzrv]

Build will create an isolated environment using the backend specified by the project. This is the whole point of PEP 517 &co, no? 🤔

No, we are building packages for a system-wide distribution context in which we control the versions that we install/provide/build with. In our case we build using

python -m build --wheel --no-isolation

see https://gitlab.archlinux.org/archlinux/packaging/packages/python-django-filter/-/blob/f2864d79f3ce32f6b2c7c85b381fa7f981df0dbe/PKGBUILD#L46

Given flit v4 exists, making an adjustment here looks fine, but I need to grasp why what's there is broken vs (merely) using the older version for the build?

We can't use it anymore. It has been replaced by flit_core 4.0.0 two months ago.

[dvzrv]

Changed to <5.

[carltongibson]

OK, thanks. 👍

[github-actions]

Coverage report

This PR does not seem to contain any modification to coverable code.