Add upper bounds for all versions, and test accordingly

[maresb]

Description

We release frequently enough that I believe it's feasible to have upper and lower bounds for all direct dependencies. This will help prevent breakage that sometimes comes with new Numpy versions, new Python versions, or similar. This isn't completely foolproof since there might be problems with transitive dependencies. But I think it would go a long ways towards preventing a lot of very unpleasant incidents.

[ricardoV94]

The issue I see with this, is that it will eventually make some combinations incompatible needlessly.

Someone for some reason wants to use the current PyTensor version with Numpy 3.x in 2028 and by miracle that would work fine, but the requirements forbid it

[maresb]

I think ☝️ is desirable behavior because probably it won't work fine. If someone in 2028 wants to use the 2024 PyTensor, they should also be using the 2024 Numpy. If a software archaeologist wants to perform bizarre experiments, then they can force-install the versions they want, and they're on their own.

The alternative is that someone in 2028 wants to use 2024 PyTensor but ends up with an incompatible Numpy 3.x. This gives someone a chance at reproducibility if they didn't make a lockfile. (Remember that person who wanted to know the dependencies for some ancient PyMC version?)

[ricardoV94]

The example version/dates were extreme, but at some point some users will start to consider them too restrictive. I would not like to lose users over that.

Before following this strategy, would be helpful to see if anyone else is doing it and whether they had an open discussion on why they chose to do so.

[maresb]

@carlsmedstad, do you have any opinions on this matter? The idea would also be to add automation to ensure the upper pins stay up-to-date.

[maresb]

Also note that unlike #593 I'm only concerned here with runtime dependencies.

[carlsmedstad]

I'm leaning towards @ricardoV94 sentiment, in my experience it's more prevalent for version bounds to cause problems due to being needlessly strict, rather than too permissive.

I think bespoke "best guess" upper version bounds, like numpy<2 or python<3.12 for example, will cause less issues than strict "latest available exact version at the time of release" bounds.

Take this with a grain of salt though - My opinion is mostly based on what works well when packaging for Arch Linux.

[maresb]

Agreed. Putting an upper-bound on the patch version will likely just prevent bugfixes. But I think the current situation of having no upper-bounds at all is pretty bad.

Since everyone has their own interpretation of semver it makes a lot of sense to choose major/minor/patch on a case-by-case basis.