Specified Python version constraint is much more restrictive than what documentation states

[lightspot21]

I have a Python project with semver constraint: python = "^3.10".

Attempting to install pygls as dev dependency fails with the error:

The current project's Python requirement (>=3.10,<4.0) is not compatible with some of the required packages Python requirement:
  - pygls requires Python <3.11,>=3.7, so it will not be satisfied for Python >=3.11,<4.0

This makes sense, but the documentation says that Pythons 3.7 and later are all supported. Is there another reason the version constraint is set like this and not just >=3.7,<4.0 or am I misunderstanding something?

Thanks in advance!

[tombh]

It should be fine shouldn't it!? Is this to do with Pygls' ordering of the versions. <3.11,>=3.7 is back to front, it would be more natural as >=3.7,<3.11.

Although I'm not clear where will not be satisfied for Python >=3.11,<4.0 suddenly appears from? So your project actually requires 3.11 not 3.10? 3.11 is still only a release candidate right? Whilst Pygls should in theory work with 3.11 we haven't proved that yet, and so haven't relaxed the version constraints. There is this issue that suggests there are compatibility issues with 3.11, but there's also been updates that could have fixed that. So 3.11 is definitely on the roadmap, just not a high priority until 3.11 is released.

[lightspot21]

@tombh

Well, I did some research and found out it has to do with how Poetry (the resolver I use) resolves dependencies based on the main project's Python version. FAQ entry: https://python-poetry.org/docs/faq#why-is-poetry-telling-me-that-the-current-projects-python-requirement-is-not-compatible-with-one-or-more-packages-python-requirements

In short, the constraint python = "^3.10" implies any 3.x version newer than (and including) 3.10. This maps to the compatibility range >=3.10,<4.0. Now, pygls by capping the max Python version to <3.11 sets a range of compatibility that looks like >=3.7,<3.11, which means that any Python in the range >=3.11,<4.0 is (from Poetry's perspective) not suitable for pygls.

So in the end, all the above mean that whoever uses Poetry and attempts to install pygls, their dependency resolution will fail (unless they constrain their project's Python version to python = ">=3.7,<3.11", which may or may not be possible.

Thus, I ask: Since pygls is said to work with any Python >= 3.7, would it be possible to change the Python version requirement that pygls defines to >=3.7,<4.0 instead of >=3.7,<3.11, so that:

1) Poetry and possibly other resolvers don't fail for no apparent reason?

2) the constraint matches the docs?

If that's not possible, an update at the docs could be done to specify that Pythons >3.11 are not supported.

[tombh]

Thank you for the explanation, I understand now, and I'm sure we'll be able to find a solution because I think your situation isn't at all an edge case.

So what I need to understand is that Python, or indeed Semantic versioning in general, offers a guarantee that minor version updates will not break existing behaviour. Therefore, as long as Pygls retains its own behviour, we can reasonably assert that Pygls will work for all future versions of Python 3?

[lightspot21]

Thank you for the explanation, I understand now, and I'm sure we'll be able to find a solution because I think your situation isn't at all an edge case.

So what I need to understand is that Python, or indeed Semantic versioning in general, offers a guarantee that minor version updates will not break existing behaviour. Therefore, as long as Pygls retains its own behviour, we can reasonably assert that Pygls will work for all future versions of Python 3?

Minor version updates, according to the SemVer spec mean add functionality in a backwards compatible manner. This is not an iron-clad guarantee of course, but in general efforts are taken to not break APIs willy-nilly without major version updates - that's the point of using semver after all, to let users know that significant breakage is incoming and prevent them from auto-updating into a possible catastrophe.

Whether Pygls keeps working mostly depends on what Python features it uses in a specific point in time, and which Python versions it is tested against. If Pygls stays at using Python 3.7 features and doesn't use stuff that got added in newer versions (or it uses new stuff but in a way that older Python versions can keep working), then it should keep working for any future version, at least until:

a) you want to use a feature added in e.g. 3.8 and you have no way or desire to keep older Pythons working

b) some Python 3.7 feature that you use and gets deprecated in, say, 3.14 (but you'll know a couple versions in advance of course that said feature is deprecated)

Let me know if any clarification is needed.

[tombh]

I've submitted a PR to relax Python to <4, see #270. Does that look good?

[lightspot21]

I've submitted a PR to relax Python to <4, see #270. Does that look good?

@tombh yep, should be okay, thanks!

[tombh]

Latest version of Pygls is public, let me know if it still doesn't fix it for you: https://pypi.org/project/pygls/0.12.2/

[lightspot21]

@tombh It's working now. Many thanks!

[jayqi]

Hi @tombh,

This got set back to <3.12 in https://github.com/openlawlibrary/pygls/pull/279 which is once again causing the dependency resolution problems that were originally reported in this issue.

[tombh]

Oh damn.

Thanks for reporting. I've made a PR https://github.com/openlawlibrary/pygls/pull/318

[tombh]

I've just published v1.0.1 to Pypi with the fix https://pypi.org/project/pygls/1.0.1/