Refactor flake.nix to remove flake-utils #177
Conversation
toastal
force-pushed
the
remove-flake-utils
branch
from
1ec4bb0 to
3515b0a
Compare
toastal
force-pushed
the
remove-flake-utils
branch
from
3515b0a to
58004ac
Compare
|
There’s probably another, perhaps better way to achieve this, but there should be a goal to not be adding dependencies to users’ |
There is no reason to be sending downstream dependencies for a for loop.
toastal
force-pushed
the
remove-flake-utils
branch
2 times, most recently
from
18ba70c to
9f648d8
Compare
You will have trouble using this tho with direnv since `use nix` is hard-coded into the project’s `.envrc`
toastal
force-pushed
the
remove-flake-utils
branch
from
9f648d8 to
04520f6
Compare
|
Split into 2 commits in case someone is opposed to adding the |
| { flake-utils, self }: | ||
| flake-utils.lib.eachDefaultSystem ( | ||
| system: | ||
| let | ||
| result = import ./default.nix { inherit system; }; | ||
| in | ||
| { | ||
| packages = result.packages // { | ||
| default = result; | ||
| }; | ||
| { self, nixpkgs }: |
There was a problem hiding this comment.
You removed flake-utils, but added nixpkgs (and that without an inputs entry, which then runs into NixOS/nix#7422). And if you don't commit the lockfile as here, we'll run into further non-reproducibility. Alternatively if you do commit the lockfile, we'll have two Nixpkgs versions that need to be fetched for the flake.
So, I don't think we should do this.
There was a problem hiding this comment.
How is the current version using the builtins dependencies of flake-utils being more reproducible than using the lib from Nixpkgs? Seems most folks are used to passing in inputs.nixpkgs.follows thru their flakes. I suppose you could get lib from npins, but really after thinking about it, might it just be simpler to manually write out x86_64-linux, et al. for system.exposedFlakes and remove all dependencies then? It’s more repetitious “code”, but has zero dependencies. I would be willing to write it out.
There was a problem hiding this comment.
IIRC, 32-bit Linux is one of the supported systems in Hydra but is missing from flake-utils’s defaultSystems.
There was a problem hiding this comment.
How is the current version using the
builtinsdependencies offlake-utilsbeing more reproducible than using the lib from Nixpkgs?
Just because in the current PR at least, Nixpkgs isn't pinned, while flake-utils is. Without committing the lockfile to pin it, people will get different results at different points in time.
Seems most folks are used to passing in inputs.nixpkgs.follows thru their flakes
That doesn't actually work, the npins-pinned Nixpkgs can't be overridden like that (see #166 for what works instead)
might it just be simpler to manually write out
x86_64-linux, et al. forsystem.exposedFlakesand remove all dependencies then? It’s more repetitious “code”, but has zero dependencies. I would be willing to write it out.
Actually one thing that flake-utils allows you is to use the https://github.com/nix-systems/nix-systems pattern, which allows consumers to work around the problem of Flakes requiring a hardcoded list of systems. This wouldn't be possible anymore if we hardcode the systems locally.
There was a problem hiding this comment.
Okay. Fair assessments as I misunderstand the environment. Thank you for explaining as I don’t see many places with a flake.nix & not using Nix to pin their Nixpkgs as well (which is why it feels like Nixpkgs is always a given).
| devShells = forAllSystems (system: { | ||
| default = result.${system}.shell; | ||
| }); |
There was a problem hiding this comment.
What's the motivation for this?
There was a problem hiding this comment.
Using nix develop over nix-shell for its caching, or being able to add the shell to another dev environment if one really wanted. The information to make it exists, & it’s little to expose it.
There was a problem hiding this comment.
Makes sense, sounds fine to have this :)
Personally I'm using https://github.com/nix-community/nix-direnv, which also caches the shell for speed
There was a problem hiding this comment.
If the flake-utils part is staying, I could just put in this commit & axe the other.
There is no reason to be sending downstream dependencies for a for loop. Includes missing devShells.