NixOS / nixops

NixOps is a tool for deploying to NixOS machines in a network or cloud.
https://nixos.org/nixops
GNU Lesser General Public License v3.0
1.87k stars 364 forks source link

eval-machine-info.nix: add nixpkgsPath argument. #1331

Closed dhess closed 4 years ago

dhess commented 4 years ago

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.

lovesegfault commented 4 years ago

It'd be nice if this added docs on how to pin nixpkgs too :)

dhess commented 4 years ago

@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 niv for this, and the general method I use to do it can be found here:

https://github.com/hackworthltd/hacknix-lib/blob/7d2cf1abaf8ef6ea30bb888a725123291227424c/nix/default.nix

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.

lovesegfault commented 4 years ago

@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 nixpkgsPath when using nixops. In other words, I already use niv, I have my own nix/default.nix, now how do I point NixOps to it?

dhess commented 4 years ago

@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 niv with a pinned nixops and nixpkgs, just do something like this:

nixpkgsPath = (import sources.nixpkgs {}).path;
nixops = import sources.nixops { inherit nixpkgsPath; };

I can see how that would be helpful in the NixOps documentation, but I'm not sure how to express concisely without dragging niv into it, as the non-niv ways are quite a bit more involved.

lovesegfault commented 4 years ago

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].
lovesegfault commented 4 years ago

cc. @cole-h who is good at explaining

cole-h commented 4 years ago

"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 niv, to put the execution into more concrete terms?

adisbladis commented 4 years ago

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?

dhess commented 4 years ago

@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?

lovesegfault commented 4 years ago

I really hope that it is possible to pin nixpkgs without having to use flakes

adisbladis commented 4 years ago

I think https://github.com/NixOS/nixops/pull/1369 is a better solution to this problem, it feels less ad-hoc than a path and is possible to use with overlays.

lovesegfault commented 4 years ago

Works for me :)

adisbladis commented 4 years ago

Closing this in favour of #1369