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

wheel unpack does not accept an archive with normalized .dist-info directory name #411

Open
MrMino opened this issue Jul 15, 2021 · 7 comments
Labels

Comments

@MrMino
Copy link

MrMino commented Jul 15, 2021

If a package with capital letters in the name ends up with lower-case .dist-info name, wheel unpack complains:

Missing Django-3.2.5.dist-info/RECORD file

Per the spec, this is the proper naming and it should be accepted.

Repro:

cd /tmp/
pip download --no-deps django==3.2.5
wheel unpack Django-3.2.5-py3-none-any.whl
mv Django-3.2.5/Django-3.2.5.dist-info Django-3.2.5/django-3.2.5.dist-info
wheel pack Django-3.2.5
mv django-3.2.5-py3-none-any.whl Django-3.2.5-py3-none-any.whl
wheel unpack Django-3.2.5-py3-none-any.whl
@agronholm
Copy link
Contributor

Although this was never mentioned in the wheel PEP, I think it's implied that wheel should normalize the name of the .dist-info directory. This has not come up before, so I would feel more comfortable if a consensus regarding the change in wheel's behavior should be changed. At any rate, wheel should be more lenient when checking for the existence of the .dist-info directory in the wheel file.

@MrMino
Copy link
Author

MrMino commented Aug 11, 2021

@agronholm My impression is that the PyPA spec pages were meant to be the authority on that topic, as long as they don't conflict with the PEPs.

https://www.pypa.io/en/latest/specifications/

This section may also include clarifications, amendments and additional guidance for specification implementors in cases where the corresponding PEPs have yet to be updated appropriately.

Anyway, I'd say wheel should be able to take in both, and at the same time be strict in what it outputs. I guess the latter would break compatibility with older versions, is that the issue?

@agronholm
Copy link
Contributor

Wheel code predates this specification. Up until now, nobody had raised the issue (and I didn't write the affected code). I'll look into using some of the functions in packaging to normalize the name in the Wheel class.

Anyway, I'd say wheel should be able to take in both, and at the same time be strict in what it outputs. I guess the latter would break compatibility with older versions, is that the issue?

I anticipate that the folks who care about reproducible wheels may raise an issue, but I think it's worth it to fix wheel code to work according to the (amended) specification.

@agronholm
Copy link
Contributor

agronholm commented Aug 18, 2021

I gave this a go about some tests fail because I used packaging.utils.parse_wheel_filename() which normalizes the names "wrong". For example, unicode.dist becomes unicode-dist while it should become unicode_dist. I'm still trying to find a proper normalization function from packaging, and if I can't, I'll just write one myself.

@agronholm
Copy link
Contributor

Actually, the spec says This is equivalent to PEP 503 normalisation followed by replacing - with _ so I just need to add one more step of doing the dash to underscore replacement.

@agronholm
Copy link
Contributor

There's a PR now, but I got to thinking: doesn't this spec imply that the file name generated by bdist_wheel should also be normalized?

@mattip
Copy link
Contributor

mattip commented Aug 19, 2021

Sounds right. Are there any potential breakages by potentially changing the names? What happens if someone mixes wheel versions on the various platforms used to build wheels, could they get differently-named packages on PyPI?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants