Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

jsonschema == 3.0.0a2 is not compatible with python 3.8 and above #34

Closed
MartinWallgren opened this issue Jun 10, 2021 · 0 comments · Fixed by #35
Closed

jsonschema == 3.0.0a2 is not compatible with python 3.8 and above #34

MartinWallgren opened this issue Jun 10, 2021 · 0 comments · Fixed by #35
Labels
bug Something isn't working

Comments

@MartinWallgren
Copy link
Contributor

MartinWallgren commented Jun 10, 2021

Description

jsonschema generates the below deprecation warning in python 3.7

======================================================================================================================= warnings summary ========================================================================================================================
../../../../.cache/pypoetry/virtualenvs/reactor-MehGalhR-py3.7/lib/python3.7/site-packages/jsonschema/compat.py:6
../../../../.cache/pypoetry/virtualenvs/reactor-MehGalhR-py3.7/lib/python3.7/site-packages/jsonschema/compat.py:6
  /home/martinwa/.cache/pypoetry/virtualenvs/reactor-MehGalhR-py3.7/lib/python3.7/site-packages/jsonschema/compat.py:6: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working
    from collections import MutableMapping, Sequence  # noqa

-- Docs: https://docs.pytest.org/en/stable/warnings.html

The issue has been fixed in newer versions of jsonschema (python-jsonschema/jsonschema#694) but since there is a hard requirement on an explicit version in eiffellib all users of the lib are stuck on python 3.7

I propose a less restrictive version declaration of jsonschema (at least a proven version but no more than the next major).
If all libraries require explicit versions it would be near impossible to use more than a handful of dependencies before dependency resolution becomes impossible due to conflicting version requirements.

Motivation

All users of the eiffellib are stuck on python 3.7

Exemplification

All users of the eiffellib are stuck on python 3.7

Benefits

Users of this lib can use the latest python versions.
Users of this lib will have an easier time to combine this lib with other libraries that also depend on jsonschema.

Possible Drawbacks

The drawback is of course less control of the version. But should a client of this lib be nervous about that they should use a constraints with explicit versions of transient dependencies.

@magnusbaeck magnusbaeck added the bug Something isn't working label Jun 10, 2021
MartinWallgren added a commit to MartinWallgren/eiffel-pythonlib that referenced this issue Jun 10, 2021
Declaring fixed version numbers for requirements makes it hard to
impossible to use eiffellib in certain circumstances. Libraries should
always declare as open dependencies as possible to allow some
flexibility for the clients.

Should a client not want to allow for this flexibility they can always
use a constraints.txt (pip) or poetry.lock (poetry) to lock down the
version numbers for any transient dependencies. The other way around is
impossible, i.e allow a less restrictive version requirement and the
declared requirement from the package.

Increasing the jsonschema from an alpha version to the actual release
resolves eiffel-community#34. Requiring an alpha release when the actual release was
finalized over two years ago is sort of wicked.
t-persson pushed a commit that referenced this issue Jun 11, 2021
Declaring fixed version numbers for requirements makes it hard to
impossible to use eiffellib in certain circumstances. Libraries should
always declare as open dependencies as possible to allow some
flexibility for the clients.

Should a client not want to allow for this flexibility they can always
use a constraints.txt (pip) or poetry.lock (poetry) to lock down the
version numbers for any transient dependencies. The other way around is
impossible, i.e allow a less restrictive version requirement and the
declared requirement from the package.

Increasing the jsonschema from an alpha version to the actual release
resolves #34. Requiring an alpha release when the actual release was
finalized over two years ago is sort of wicked.

Co-authored-by: Martin Wallgren <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants