-
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
Pin our own npins #85
Comments
The 2nd or 3d option sounds best. The 2nd might be the best for dogfooding. The 3rd option has the problem of migrating. If you are changing something (e.g. new version of the JSON file) you'll have to update the pinned |
I don't think that's a problem in the 3rd option, because |
Then we'd at least need some CI check that the pinned version doesn't require a newer / older version of the manifest. |
Currently the dev shell does not provide an
npins
, leaving users to use a globally installed one. This causes issues when developing new features, where thesources.json
may require a newer version than the user has installed. In that case,cargo run --
must be used instead. Another issue is that thenpins/default.nix
is both used as the ground truth for the application as well as for dogfooding. In the end, I see the following options:./.
) as thenpins
to use in the shellnpins=cargo run --
alias in the shell. This avoids having to rebuild the entire derivation after each changenpins/default.nix
in thenpins
binary. (Instead, copy it to some resources folder elsewhere)Personally, I prefer the last option.
The text was updated successfully, but these errors were encountered: