pip defaults to older tabpfn version when you have python3.13.

[LeoGrin]

Our current version doesn't support python3.13, but this was not specified for past tabpfn versions (though they probably don't support it either), so pip default to installing these older versions if you have python3.13 instead of saying that we don't support python3.13. This creates hard to understand issues like #203 where people don't realize they have an older tabpfn version

Solutions:

• support python3.13: we should do it either way, but we'll have the same issue when python3.14 comes out.
• yank all the older versions (incorrectly) supporting new python versions (Note: might need to change the instructions for old version pip install tabpfn<2)

[mert-kurttutan]

I am curious as to why there is an upper bound on the python version. If the user is using prerelease version of python, it is their responsibility since the python version is not stable yet.

The only problem that I could see is with third party libraries not supporting stable and very new python version (or not providing wheels for it). In this case, it is kind of responsibility of user to deal with the installation of pytorch, which is ok since they can't install pytorch to begin with.

This is also standard convention across many python libraries I have seen. Pytorch, numpy all use no upper bound on python version.

Regarding past library versions, one can introduce a new minor-minor version (e.g. 2.0.1 -> 2.0.1.1) (with the current python requirements) to the past version so hopefully this minor version will be picked up by their package manager.

I have not seen this trick being used, but as far as pep standards go see here this is valid.

[LeoGrin]

Thanks @mert-kurttutan, these are great points! It's true that we could get rid of the max python version altogether.
I still like having a max version, as it makes it very clear to the user that we don't support their version, and adventurous users can always use the --ignore-requires-python flag. For larger packages with a larger maintainer team, I think the tradeoffs are a bit different because they can make sure to support the newest python versions before their release, which we'll try to do but might not guarantee.

[LeoGrin]

For now I've yanked the older tabpfn versions which did not specify max python version, but the error you get with python3.13 is not great either:

pip install tabpfn
ERROR: Ignored the following yanked versions: 0.1, 0.1.1, 0.1.2, 0.1.3, 0.1.5, 0.1.7, 0.1.8, 0.1.9, 0.1.10, 0.1.11, 2.0.0, 2.0.1
ERROR: Could not find a version that satisfies the requirement tabpfn (from versions: none)
ERROR: No matching distribution found for tabpfn

[mert-kurttutan]

That type control is needed only if the other packages exhibit very weird error on their semver rules, which I dont have the emprical evidence of, or python does not obey semver rules, which again is not possible.

I guess we disagree on this point,

Why not just release new minor version on python 3.13? Right after pytorch release? They seem pretty good as far as semver goes. So transition 3.12->3.13 seems easy in theory.

For instance 3.13 is the default version that installs in the current venv managers, e.g. uv

D:\tmp\blog> uv venv .venv
Using CPython 3.13.1
Creating virtual environment at: .venv
Activate with: overlay use .venv/Scripts/activate.nu
D:\tmp\blog>    

That kind of friction for new users seems important. Some might not even know what is wrong and not report and work with some other tool that works on default python version, which is 3.13 in some venv managers.

[LeoGrin]

Why not just release new minor version on python 3.13? Right after pytorch release? They seem pretty good as far as semver goes. So transition 3.12->3.13 seems easy in theory.

Yes once we release a new version which supports python3.13 we have no problem, the question is what to do for new python versions while we don't support them yet. It's possible I haven't understood the solution you're suggesting though.

[mert-kurttutan]

My suggestion is to release the new version for 3.13 as soon as that python version (+new torch release for that python version) is out.
Like right now(or even middle of last month), it is seems ok to release that version.

[LeoGrin]

#240 will add python3.13 support, and remove the max python version.
I've actually changed my mind on specifying a maximum python version after this conversation (thanks @mert-kurttutan) and reading this: https://discuss.python.org/t/requires-python-upper-limits/12663/79
People seem to be converging on avoiding upper versions, and upper versions are even ignored by some package managers like uv now. It can also create annoying issue for people depending on our package like this one: pdm-project/pdm#2339 (we might want to also think about that for max package version in general).