Consider deferring cache saving to the action post step

[olivier-lacroix]

Currently, the cache saving happens just after the install step.

Deferring cache saving to the post stage would allow caching "more", and in particular, caching the output of tasks that carry out some environment setup.

For instance, we are using gcloud and some optional components, that can be installed via a gcloud components install command. Currently, this cannot be cached by the setup-pixi action, as the cache is saved before we can run the task.

In addition, this would allow removing the cache saving from the 'hot path' (granted, it's pretty quick, and not called that often).

Do you see any downside in deferring cache saving to the setup-pixi action post step?

[pavelzw]

Yes, this makes it possible for people (or unintended side effects) to produce broken/weird pixi environments. There might also be tasks that are not idempotent and modify the .pixi folder. Those would break through your suggestion.
Another example might be when you use pixi-inject to post install a .conda file into your env. If this were cached, pixi install would always need to remove this file just because the cache is not proper and it looks to pixi like it needs to uninstall something.

I personally don't like this approach and have explicitly opted for uploading the cache immediately so that nobody can meddle in the files. This ensures that the cache is a "proper" pixi environment that pixi would produce exactly that way.

If you really want this behavior, you could also deactivate the caching in setup-pixi and have a manual uses: actions/cache before the setup-pixi call. This should result in your desired behavior.

Caching is a topic that one should imo only use if it's done properly. If you can't rely on your cache because of some shenanigans, you will eventually end up with great misery.

[olivier-lacroix]

Thanks @pavelzw for the quick answer. Using actions/cache to handle caching is indeed a valid solution. It would however require recreating the setup-pixi hashing / cache key logic.

Would you be open to a PR that introduces an option to defer caching to the post stage, with the right warning signs and all that 😃. Completely understand you may consider it too big a footgun and would rather not allow it at all.