feat: Implement a --use-cache flag closes #100

[awesomebytes]

Motivation

Following up on #100 (thanks for the opportunity @pavelzw !).

As the README of this PR states, having a cache for downloads is useful when:

• Creating multiple packs with overlapping dependencies
• Working with large packages that take time to download
• Operating in environments with limited bandwidth
• Running CI/CD pipelines where package caching can significantly improve build times

pixi's cache is for already-extracted packages, but here we need them un-extracted, so implementing an optional (behind the --use-cache flag) cache for downloads.

I have little experience in Rust[1], let me know if this is an okay implementation.

There are some formatting changes, I used the autoformat feature from VSCode with the rust-analyzer extension.

Changes

• Added a --use-cache CACHE_DIR flag.
• Added implementation for it in the download function.
• Added a test for it.
• Added README docs about it.

[1] It's so easy to jump into a project thanks to cargo! I just cloned, ran cargo build, then cargo test (which failed due to my slow internet)... and then I could just cargo run to test my changes (before I added my test, which I should probably have done first).

closes #100

[awesomebytes]

Note that for the integration tests, if you wish, cache could be used. Particularly:

• test_reproducible_shasum does two pack operations in a row

Or, having a global cache for all the tests, would accelerate them all anywhere where the internet is not super fast (and running the tests will hit the hosting servers less). But this may mess with expectations of the tests or their particular goals. I did not want to implement that in case it was too controversial.

[pavelzw]

Note that for the integration tests, if you wish, cache could be used

i don't think this is necessary. but as mentioned in #104 (comment), i think it would be nice to assert that the SHA stays the same even with cache

[awesomebytes]

Oh, also, there's no short-version of the --use-cache flag, that may be a taste thing. I think it would default to -u which feels awkward. And -c doesn't convince me either (--create-executable doesn't have one, and would default to c?).

So, yeah, if it should have a short-version, you should probably be the ones to decide which :)

Also, I chose to make --use-cache USER_PROVIDED_DIR over --use-cache without any arguments as I would most probably see the need to be able to specify the location anyways (e.g. /tmp /shm /some_shared_folder).

[pavelzw]

So, yeah, if it should have a short-version, you should probably be the ones to decide which

i think only having a long version should be fine here

I chose to make --use-cache USER_PROVIDED_DIR over --use-cache without any arguments

sounds sensible 👍🏻

[awesomebytes]

@pavelzw all ready, I think :)

[delsner]

LGTM, thanks for implementing this so quickly!

[awesomebytes]

Thank you for the tool and the opportunity!

Any comment in regards of the code/tests? For me to learn, basically

[pavelzw]

thanks, code looks good to me!

[pavelzw]

failing ci is intended as --create-executable doesn't work with a non-existent release