-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
[BUG] Rich is too restrictive on dataclasses dependency #446
Labels
Comments
ssbarnea
changed the title
[BUG] Rich is too aggressive on dataclasses dependency
[BUG] Rich is too restrictive on dataclasses dependency
Nov 26, 2020
ssbarnea
added a commit
to ssbarnea/molecule-podman
that referenced
this issue
Nov 26, 2020
It seams that our tox -e py36-devel is also affected by the endless loop install bug from the new resolver, we are forced to disable it, at least for this job. Example: https://github.com/ansible-community/molecule-podman/pull/23/checks?check_run_id=1458663833 Related: pypa/pip#6536 Related: Textualize/rich#446
ssbarnea
added a commit
to ansible-community/molecule-podman
that referenced
this issue
Nov 26, 2020
It seams that our tox -e py36-devel is also affected by the endless loop install bug from the new resolver, we are forced to disable it, at least for this job. Example: https://github.com/ansible-community/molecule-podman/pull/23/checks?check_run_id=1458663833 Related: pypa/pip#6536 Related: Textualize/rich#446
ssbarnea
added a commit
to ssbarnea/molecule-podman
that referenced
this issue
Nov 26, 2020
It seams that our tox -e py36-devel is also affected by the endless loop install bug from the new resolver, we are forced to disable it, at least for this job. Example: https://github.com/ansible-community/molecule-podman/pull/23/checks?check_run_id=1458663833 Related: pypa/pip#6536 Related: Textualize/rich#446
I'm not sure if dataclasses follows semver, and even if it does, the 0 major version allows for breaking changes. Until they release 1.0 I think its wise to check compatibility before a release. I'd rather issues were flagged at built time than expose apps to potential bugs. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Few minutes ago I got some pip install failures which, IMHO are caused by being too restrictive regarding supported versions.
I know a bump happened on on Nov 10 but no release was made since. Still, I do think that the version compatibility range should not have a ceiling bound unless it is already known to break the library.
This is particularly problematic with rich which is mostly a library, so it needs to play well with other dependencies the project may need.
Lets assume you make 9.2.1 hotfix today to sort this issue. What happens if dataclasses makes release 0.9 tomorrow, it will likely get into conflict with rich again, even if there is no proof that they do not work together. This is even more problematic as the ceiling seams to be applied to the minor version.
If the concerns around possible breakage produced by dataclasses are real, at least the conditions should look more like
<1.0
.The text was updated successfully, but these errors were encountered: