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
eval-machine-info.nix: add nixpkgsPath argument. #1331
Conversation
It'd be nice if this added docs on how to pin nixpkgs too :) |
@lovesegfault I think that's out of scope for this change, or even for NixOps in general. Pinning nixpkgs is now a fairly common practice in nixpkgs-based projects, it can be done in a multitude of ways, and it wouldn't be practical to document it everywhere that it's supported :) My preference these days is to use But that's just one way to do it and it would be a bit much to try to document this in NixOps, in my opinion. |
@dhess I completely failed to express what I meant over there, my bad! I meant to ask whether it would make sense to add docs on how to/where to set |
@lovesegfault Ahh, I see what you meant. No worries! It's really quite easy now that @grahamc and @adisbladis have done all this nice refactoring work. Assuming you're using
I can see how that would be helpful in the NixOps documentation, but I'm not sure how to express concisely without dragging |
Maybe something like: # Pinning Nixpkgs
You can pin `nixpkgs` by enforcing `nixpkgsPath` on your call to `nixops`.
For example, assuming you had `myNixpkgs` pinned you can do
`callPackage nixops { nixpkgsPath = myNixpkgs; }`
For more information on pinning nixpkgs see [insert helpful link here maybe https://nixos.wiki/wiki/FAQ/Pinning_Nixpkgs]. |
cc. @cole-h who is good at explaining |
"Good" is stretching it. I've slightly improved upon your suggestion with the following: # Pinning Nixpkgs
You can pin the `nixpkgs` that `nixops` will use by setting the `nixpkgsPath`
argument.
Assuming you have `myNixpkgs` pinned (see the [FAQ on pinning
Nixpkgs](https://nixos.wiki/wiki/FAQ/Pinning_Nixpkgs) for more information), you
could overlay `nixops` with the following:
```nix
{
# myNixpkgs = ...
nixpkgsPath = myNixpkgs.path;
nixops = callPackage ./path/to/nixops { inherit nixpkgsPath; };
}
whycantiescapethesewithabackslash``` I only worry that this is too abstract... Maybe another example following it that takes advantage of |
This allows the caller to use a pinned nixpkgs, rather than the <nixpkgs> default value.
0490063
to
aff261b
Compare
We have merged support for defining a network in a flake, this will use the flake-pinned nixpkgs version. Is this good enough for you @dhess? |
@adisbladis Tough for me to say as I haven't used flakes yet, but I can see where the winds are blowing. Shall I close this, then? |
I really hope that it is possible to pin nixpkgs without having to use flakes |
I think #1369 is a better solution to this problem, it feels less ad-hoc than a path and is possible to use with overlays. |
Works for me :) |
Closing this in favour of #1369 |
This allows the caller to use a pinned nixpkgs, rather than the
<nixpkgs>
default value. Among other things, this makes it possible to build at least some NixOps networks on a Hydra (or from any Nix expression), which addresses #1320.