-
Notifications
You must be signed in to change notification settings - Fork 18
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
Support specifying release artifact to prehash #44
Comments
A release may have multiple uploaded artifacts, do I understand correctly that the idea is to provide the artifact name? And how should this interact across versions when updating?
That sounds weird to me. Usually, source and release have wildly different content, and simply swapping one for the other wouldn't help many people. |
Yes, the idea is that we provide an artifact name that would be fetched from this URL:
In hindsight, it does sound weird. Nevermind the idea. |
What should happen on update if a release does not have a GitHub release, or the release does not have the desired artifact? Maybe tangential, but it would be easy to create a pin type for fetching URLs, like a thin wrapper around |
I think erroring out is the best solution. If the artifact should exist but doesn't, then either upstream forgot about it, or there was a good reason to not include it anymore. Either way, it's the user's business from then on.
Why not? Currently, we can use the version provided by npins and use it for other fetchers. It's not exactly efficient when you don't need the source, but it does work. |
I fear that this may require adding support for artifact names which reference the current version to be useful, which does not sound like fun implementing :/ |
I use npins in my nix-gaming repo to automate updates. It's working great, but for some games I want to download a release artifact (compiled tarball/AppImage) instead of the source tarball. Since npins does not provide that functionality, I had to write update scripts for certain games (see this).
It would be great to have an option to specify the release artifact to get the hash for. Also, in case the artifact does not exist, the system could fallback to hashing the source tarball.
Another (maybe unrelated) feature request would be using SRI hashes, to be able to simply
inherit (pins.some-pin) hash
inside most fetchers.The text was updated successfully, but these errors were encountered: