rich icon indicating copy to clipboard operation
rich copied to clipboard

[BUG] Github source release has wrong version

Open bnavigator opened this issue 1 year ago • 8 comments

The tag https://github.com/Textualize/rich/releases/tag/v12.5.1 references the wrong commit, where pyproject.toml still has 12.5.0, this results in the wrong source tarball.

The release should have referenced https://github.com/Textualize/rich/commit/cde23ed0a1ecad8c63436148c7e1fb6f0073fca8

bnavigator avatar Jul 20 '22 20:07 bnavigator

I recently encountered this in NixOS where one of my packages depends on rich 12.5.1. But pip fails due to the Github tag referencing a commit that says it's version 12.5.0. Are there any plans to fix this issue?

arjan-s avatar Aug 16 '22 20:08 arjan-s

What error did you get?

Happy to fix it if you can suggest how.

willmcgugan avatar Aug 16 '22 20:08 willmcgugan

Pip shows the following error:

> ERROR: Could not find a version that satisfies the requirement rich<13.0.0,>=12.5.1 (from pls) (from versions: none)
> ERROR: No matching distribution found for rich<13.0.0,>=12.5.1

The easiest fix would be to simply update the tag to the correct commit:

git tag -f v12.5.1 cde23ed

arjan-s avatar Aug 16 '22 20:08 arjan-s

AFAIK git tags have nothing to do with Pip.

willmcgugan avatar Aug 16 '22 21:08 willmcgugan

True, mine is a nix-specific issue. The nix package for rich is built from Github tags (source tarballs). Proof here. This is different from normal pip behaviour, because by default it uses the package from Pypi, which somehow did get the correct version number.

arjan-s avatar Aug 16 '22 21:08 arjan-s

Issuing a new release, 12.5.2, with consistent package metadata (which nixpkgs could then switch to) should also fix it.

exarkun avatar Aug 16 '22 21:08 exarkun

Issuing a new release, 12.5.2, with consistent package metadata (which nixpkgs could then switch to) should also fix it.

Or to elaborate on @arjan-s 's comment - a new git tag for a revision with consistent metadata would give nixpkgs something it could easily switch to and which would produce an installed package with consistent metadata.

exarkun avatar Aug 16 '22 21:08 exarkun

@exarkun is correct, both options would fix the issue. @willmcgugan would you be willing to do either of them?

arjan-s avatar Aug 18 '22 11:08 arjan-s

Did I solve your problem?

Why not buy the devs a coffee to say thanks?

github-actions[bot] avatar Sep 23 '22 14:09 github-actions[bot]

@willmcgugan I see you closed this as completed, but I don't see a new tag/release and the existing tag isn't fixed either... Could you please take a look again? Thanks!

arjan-s avatar Sep 27 '22 07:09 arjan-s

I ran the command you suggested.

If you are saying that a new release will fix it, then one is just around the corner.

willmcgugan avatar Sep 27 '22 08:09 willmcgugan

Ah, maybe you forgot to push after the tag command?

git push --tags

arjan-s avatar Sep 27 '22 10:09 arjan-s