Closed peterbe closed 5 years ago
Fixes #105
CC @SomberNight
First observe that for requests the sha256 digests appear in this order:
requests
7bf2a778576d825600030a110f3c0e3e8edc51dfaafe1c146e39a2027784957b
502a824f31acdacb3a35b6690b5fbf0bc41d63a24a45c4004352b0242707598e
Run it the first time:
▶ python hashin.py -r /tmp/reqs.txt requests ▶ cat /tmp/reqs.txt requests==2.21.0 \ --hash=sha256:502a824f31acdacb3a35b6690b5fbf0bc41d63a24a45c4004352b0242707598e \ --hash=sha256:7bf2a778576d825600030a110f3c0e3e8edc51dfaafe1c146e39a2027784957b
Note that 502a824... comes before 7bf2a778... which is different from the JSON from Pypi.org.
502a824...
7bf2a778...
Next, mess with the list of hashes manually:
▶ jed /tmp/reqs.txt ▶ cat /tmp/reqs.txt requests==2.21.0 \ --hash=sha256:7bf2a778576d825600030a110f3c0e3e8edc51dfaafe1c146e39a2027784957b \ --hash=sha256:502a824f31acdacb3a35b6690b5fbf0bc41d63a24a45c4004352b0242707598e ▶ python hashin.py -r /tmp/reqs.txt requests --dry-run
In other words, it didn't touch the file. It's because when it compares the previous hashes with the found hashes from pypi, it does it by comparing to sets.
set
Now really mess with it:
▶ cat /tmp/reqs.txt requests==2.21.0 \ --hash=sha256:7bf2a778576d825600030a110f3c0e3e8edc51dfaafe1c146e39a2027784957b \ --hash=sha256:502a824f31acdacb3a35b6690b5fbf0bc41d63a24a45c4004352b0242707598e ▶ jed /tmp/reqs.txt ▶ cat /tmp/reqs.txt requests==2.21.0 \ --hash=sha256:7bf2a778576d825600030a110f3c0e3e8edc51dfaafe1c146e39a2027784957b ▶ python hashin.py -r /tmp/reqs.txt requests ▶ cat /tmp/reqs.txt requests==2.21.0 \ --hash=sha256:502a824f31acdacb3a35b6690b5fbf0bc41d63a24a45c4004352b0242707598e \ --hash=sha256:7bf2a778576d825600030a110f3c0e3e8edc51dfaafe1c146e39a2027784957b
This time, the sets aren't equal so it goes to write down the hashes and when it does it does so in a sorted order.
Looks OK, and seems to work for me too. Thanks!
Fixes #105
CC @SomberNight
Here's how I tested it:
First observe that for
requests
the sha256 digests appear in this order:7bf2a778576d825600030a110f3c0e3e8edc51dfaafe1c146e39a2027784957b
502a824f31acdacb3a35b6690b5fbf0bc41d63a24a45c4004352b0242707598e
Run it the first time:
Note that
502a824...
comes before7bf2a778...
which is different from the JSON from Pypi.org.Next, mess with the list of hashes manually:
In other words, it didn't touch the file. It's because when it compares the previous hashes with the found hashes from pypi, it does it by comparing to
set
s.Now really mess with it:
This time, the sets aren't equal so it goes to write down the hashes and when it does it does so in a sorted order.