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

Enable multiple file hashing methods for backwards and forwards compatibility #4578

Closed
2 tasks done
colindean opened this issue Sep 30, 2021 · 6 comments · Fixed by #8851
Closed
2 tasks done

Enable multiple file hashing methods for backwards and forwards compatibility #4578

colindean opened this issue Sep 30, 2021 · 6 comments · Fixed by #8851

Comments

@colindean
Copy link
Contributor

  • I have searched the issues of this repo and believe that this is not a duplicate.
  • I have searched the documentation and believe that my question is not covered.

Issue

My PR #4573 improves where the hash of an archive is checked against the hashes in the lockfile. While working on that PR, I spotted a potential improvement but want to collect feedback before I implement it.

I think this area could be further improved by representing the hashes as a dataclass or something containing the hash type and the string digest. The types of hashes would be more robust then instead of hardcoding sha256 in poetry/installation/executor.py and in FileDependency.hash(). It would also enable enumeration of hash types of known hashes so that FileDependency.hash() could return a list of hashes based on requested types. Doing this might alleviate the md5/sha256 problems arising from changes in poetry-core 1.0.6+ that affect Poetry 1.1.7+ users using Artifactory in at least #4523.

I'm willing to undertake this implementation if no maintainers object.

@colindean
Copy link
Contributor Author

I'm going to undertake this!

colindean referenced this issue in python-poetry/poetry-core Oct 4, 2021
@colindean
Copy link
Contributor Author

python-poetry/poetry-core@68bf052 implemented a key part of this and I think @sdispater is heading in a similar direction…

@colindean
Copy link
Contributor Author

python-poetry/poetry-core@68bf052 is not yet in 1.0 branch nor is it in a 1.1.0 alpha release. I'm not sure of the best way to consume poetry-core master in poetry other than just changing the dependency declaration temporarily. Ideally, I'd like to see that change released…

@neersighted
Copy link
Member

This in in progress in #4486.

@neersighted neersighted linked a pull request Nov 12, 2021 that will close this issue
1 task
neersighted added a commit that referenced this issue Nov 12, 2021
This allows for much-improved compatibility when interfacing with legacy
PyPI-compatible repositories.

This is a successor PR to #4866, and closes #4578 and #4085.

Co-authored-by: Andreas Stenius <andreas.stenius@svenskaspel.se>
neersighted added a commit that referenced this issue Nov 12, 2021
This allows for much-improved compatibility when interfacing with legacy
PyPI-compatible repositories.

This is a successor PR to #4486, and closes #4578 and #4085.

Co-authored-by: Andreas Stenius <andreas.stenius@svenskaspel.se>
neersighted added a commit that referenced this issue Nov 13, 2021
PyPI-compatible repositories.

This is a successor PR to #4486, and closes #4578 and #4085.
This PR is also a forward-port of #4529.
neersighted added a commit that referenced this issue Nov 13, 2021
This allows for much-improved compatibility when interfacing with legacy
PyPI-compatible repositories.

This is a successor PR to #4486, and closes #4578 and #4085.
This PR is also a forward-port of #4529.
neersighted added a commit that referenced this issue Nov 13, 2021
This allows for much-improved compatibility when interfacing with legacy
PyPI-compatible repositories.

This is a successor PR to #4486, and closes #4578 and #4085.
This PR is also a forward-port of #4529.
neersighted added a commit that referenced this issue Nov 13, 2021
This allows for much-improved compatibility when interfacing with legacy
PyPI-compatible repositories.

This is a successor PR to #4486, and closes #4578 and #4085.
This PR is also a forward-port of #4529.
neersighted added a commit that referenced this issue Nov 13, 2021
This allows for much-improved compatibility when interfacing with legacy
PyPI-compatible repositories.

This is a successor PR to #4486, and closes #4578 and #4085.
This PR is also a forward-port of #4529.
neersighted added a commit that referenced this issue Nov 13, 2021
This allows for much-improved compatibility when interfacing with legacy
PyPI-compatible repositories.

This is a successor PR to #4486, and closes #4578 and #4085.
This PR is also a forward-port of #4529.
neersighted added a commit that referenced this issue Nov 15, 2021
This allows for much-improved compatibility when interfacing with legacy
PyPI-compatible repositories.

This is a successor PR to #4486, and closes #4578 and #4085.
This PR is also a forward-port of #4529.
neersighted added a commit that referenced this issue Nov 16, 2021
This allows for much-improved compatibility when interfacing with legacy
PyPI-compatible repositories.

This is a successor PR to #4486, and closes #4578 and #4085.
This PR is also a forward-port of #4529.
neersighted added a commit that referenced this issue Nov 19, 2021
This allows for much-improved compatibility when interfacing with legacy
PyPI-compatible repositories.

This is a successor PR to #4486, and closes #4578 and #4085.
This PR is also a forward-port of #4529.
@colindean
Copy link
Contributor Author

Thank you all especially @GMouzourou for picking up where I left off and finishing this finally!

Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 29, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.