Is it necessary to set the "require_python" upper bound to <3.13

[tyong920]

Downstream libraries or programs are limited by this ...

[mondeja]

And that's correct, we don't know yet if the library works in Python3.13. If you are very concerned about that, switch from poetry to hatch.

[GabDug]

While hatch is a great tool, it's not suitable for all use-cases: due to the absence of a standard lockfile format, there is no reproducibility. PDM or Poetry are reasonable choices when this is a requirement.

I've read your arguments in #135, and one of your point is that it's supposed to indicate versions that are guaranteed compatible, as per the Core metadata specifications. While I agree that there is no guarantee it works on Python 3.13, I think it's okay to assume forward compatibility between Python versions.
Moreover, this is what the majority of packages do, and it's also what the specifications indicates in its example. Even PyPA, the maintainers of the specification, do not specify upper-bounds on their projects like setuptools or pip.

I agree that removing the upper-bound also removes information that is easily parseable. However, the ecosystem use alternative ways, and instead convey this kind of information through standard, parseable classifiers, and to humans with badges and documentation.

Finally, if compatibility with future versions is a concern, simply adding a warning and disclaimer when running on a an unsupported-version of Python may be a fair approach.

I'll hope you'll reconsider :)

Have a great day, and thanks for this really useful package!

[mondeja]

However, the ecosystem use alternative ways, and instead convey this kind of information through standard, parseable classifiers

I haven't considered to use classifiers as a way to parse the upper version bound. Thanks. Seems feasible but I need to make some changes in the tool that I use to standarize the configuration across projects. Reopening this issue... expect it to be acomplished in a few weeks.

[tyong920]

While hatch is a great tool, it's not suitable for all use-cases: due to the absence of a standard lockfile format, there is no reproducibility. PDM or Poetry are reasonable choices when this is a requirement.

I've read your arguments in #135, and one of your point is that it's supposed to indicate versions that are guaranteed compatible, as per the Core metadata specifications. While I agree that there is no guarantee it works on Python 3.13, I think it's okay to assume forward compatibility between Python versions. Moreover, this is what the majority of packages do, and it's also what the specifications indicates in its example. Even PyPA, the maintainers of the specification, do not specify upper-bounds on their projects like setuptools or pip.

I agree that removing the upper-bound also removes information that is easily parseable. However, the ecosystem use alternative ways, and instead convey this kind of information through standard, parseable classifiers, and to humans with badges and documentation.

Finally, if compatibility with future versions is a concern, simply adding a warning and disclaimer when running on a an unsupported-version of Python may be a fair approach.

I'll hope you'll reconsider :)

Have a great day, and thanks for this really useful package!

Could't agree more! 👍

[mondeja]

The new version 6.0.2 does not include a maximum Python upper version as requirement.