Hmm. We certainly need to test the new Cython release when it comes out and the rapid Python release cycle is driving the upgrades. How do you suggest we handle that going forwards?

We certainly need to test the new Cython release when it comes out and the rapid Python release cycle is driving the upgrades. How do you suggest we handle that going forwards?

We can bump the version when it comes out. Alternatively, we can remove the upper bound from this PR and add it to the release instructions - and <=most_recent_released_cython_version at the time of creating a new release branch.

Maybe that is the lower-effort thing to do here. It's easy to forget though, and there's no good way to catch it if we do forget. What would you prefer?

If we set a specific version, wouldn’t dependabot tell us when there is a new release?

wouldn’t dependabot tell us when there is a new release?

Don't know, but I suppose putting this in is one way to find out :)

Pinning to a specific version is too strict and the current requirement may be too loose, then again this may make it too tight :) The problem is allowing sufficient flexibility for downstream projects who may have various Cython versions installed. OTOH, we want to make sure that bad Cython versions are forbidden, especially during the ongoing alpha and beta release cycle, but we also want to test those releases in order to provide feedback. Anyone know how dependabot handles alpha and beta releases? The idea of putting in an upper limit during the branch process is interesting, but maybe too easy to screw up.

The problem is allowing sufficient flexibility for downstream projects who may have various Cython versions installed.

That's not how this works, pyproject.toml is used when building from source with build isolation. Every project can put a different version in there, they won't affect each other.

Also note that this won't prevent installing a more recent version of Cython than the upper limit and running python setup.py install.

I'm not a fan of dependabot for this stuff - overly noisy for little benefit. I'd suggest always putting in the upper limit in pyproject.toml, and just updating it once in a while, e.g. right before creating a new release branch.

Let's give this a shot. Thanks Ralf.