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

Pin our own npins #85

Closed
piegamesde opened this issue Jun 14, 2024 · 3 comments
Closed

Pin our own npins #85

piegamesde opened this issue Jun 14, 2024 · 3 comments

Comments

@piegamesde
Copy link
Collaborator

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 the sources.json may require a newer version than the user has installed. In that case, cargo run -- must be used instead. Another issue is that the npins/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:

  • Pin the current development repo (./.) as the npins to use in the shell
  • Declare an npins=cargo run -- alias in the shell. This avoids having to rebuild the entire derivation after each change
  • Pin a package npins version for the shell, and stop using npins/default.nix in the npins binary. (Instead, copy it to some resources folder elsewhere)

Personally, I prefer the last option.

@andir
Copy link
Owner

andir commented Jun 14, 2024

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 npins version while proposing the changes... So we bit of a chicken-and-egg problem.

@piegamesde
Copy link
Collaborator Author

I don't think that's a problem in the 3rd option, because npins itself is not required to use the pins. So one can update npins in the dev shell first and then upgrade the pins.json.

@andir
Copy link
Owner

andir commented Jun 14, 2024

Then we'd at least need some CI check that the pinned version doesn't require a newer / older version of the manifest.

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

No branches or pull requests

2 participants