Skip to content
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

Open
fufexan opened this issue Jul 3, 2023 · 5 comments
Open

Support specifying release artifact to prehash #44

fufexan opened this issue Jul 3, 2023 · 5 comments
Labels
enhancement New feature or request

Comments

@fufexan
Copy link

fufexan commented Jul 3, 2023

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.

@andir andir added the enhancement New feature or request label Jul 18, 2023
@piegamesde
Copy link
Collaborator

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?

Also, in case the artifact does not exist, the system could fallback to hashing the source tarball.

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.

@fufexan
Copy link
Author

fufexan commented Jul 23, 2023

Yes, the idea is that we provide an artifact name that would be fetched from this URL:
https://github.com/<owner>/<repo>/releases/download/<version>/<artifactName>

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.

In hindsight, it does sound weird. Nevermind the idea.

@piegamesde
Copy link
Collaborator

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 fetchTarball. However, updating functionality would probably not exist.

@fufexan
Copy link
Author

fufexan commented Jul 23, 2023

What should happen on update if a release does not have a GitHub release, or the release does not have the desired artifact?

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.

However, updating functionality would probably not exist.

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.

@piegamesde
Copy link
Collaborator

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 :/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants