You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
resolveseiffel-community#34. Requiring an alpha release when the actual release was
finalized over two years ago is sort of wicked.
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]>
Description
jsonschema generates the below deprecation warning in python 3.7
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.
The text was updated successfully, but these errors were encountered: