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

[BUG] Rich is too restrictive on dataclasses dependency #446

Closed
ssbarnea opened this issue Nov 26, 2020 · 1 comment
Closed

[BUG] Rich is too restrictive on dataclasses dependency #446

ssbarnea opened this issue Nov 26, 2020 · 1 comment

Comments

@ssbarnea
Copy link

Describe the bug
Few minutes ago I got some pip install failures which, IMHO are caused by being too restrictive regarding supported versions.

py36:
rich 9.2.0 has requirement dataclasses<0.8,>=0.7; python_version >= "3.6" and python_version < "3.7", but you have dataclasses 0.8.

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.

@ssbarnea 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
@willmcgugan
Copy link
Collaborator

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
Projects
None yet
Development

No branches or pull requests

2 participants