If you only change the version number, guix will cry to download that version. If it fails, then it relies on the provided hash to fetch from a content-adressed store, such as ci or sohtware heritage. It relies on the hash as the source of truth.
Usually, when updating a package, I alter the hash to make sure it doesn't build the old version. Replace the initial 1 with a 0 or initial 0 with a 1, and you get a wrong hash. If it fails to download the file, you'll notice immediately. Otherwise, it will print the expected hash. Le 8 novembre 2024 20:18:54 GMT+01:00, Troy Figiel <t...@troyfigiel.com> a écrit : >Hi Juli, > >On Fri, 2024-11-08 at 13:26 -0500, Juliana Sims wrote: >> To cover all my bases, I pk'd the hash produced by `pypi-uri` and >> used >> `guix download` to try to fetch the same file and check its hash, >> only >> to find that `guix download` couldn't find anything at that URL or >> its >> fallbacks. > >It seems at some point in between version 0.14.0 and 0.17.0 the name of >the tarball has changed from `magic-wormhole` to `magic_wormhole`. You >have to change the uri-field accordingly to successfully download the >source code from PyPI. > >When building it in the way you describe, the source code cannot be >found on PyPI, so it is pulled from tarballs.nixos.org instead. It >seems NixOS uses content-addressable storage, so the hash is used to >download the source code and since you have not changed the hash, it >downloads version 0.14.0 again. > >Why tarballs.nixos.org is used as a backup, I do not know. I do not >recall ever having seen this behaviour before. > >Hope this helps a bit though! > >Best wishes, > >Troy
