Why not make it a shell alias?
That flag wouldn’t be much shorter than what you already
Shell aliases are fragile things, I really hate them.
- You have to sync them between devices.
nix buildandnix flake updateboth take--override-input, should I make two aliases for both of them? Well maybe we can doalias nix='nix --override-input nixpkgs nixpkgs'? No, this doesn’t work:error: unrecognised flag- Also
--override-input nixpkgs nixpkgsis sometimes not enough because I may have to do--override-input nixpkgs nixpkgs --override-input fenix fenixetc.
If we make it a global option in nix.conf then we will need no flag. Also a single long flag can be easily auto-completed.
1 Like
I think rather than hiding it behind the magic registry, explicit pinning for such a flag would be better. But I’m on board with a flag that aliases what nix flake lock resolves specific input names to; the effect should be transparent in flakes though, no flake:nixpkgs urls.
I.e., I think a mix of the --override-input behavior and something like the registry (except more explicit so that it’s not as footgunney) would be a nice tradeoff.
This is already quite achievable, in fairness, I’m pretty sure you can use --override-input with a flake URI, so you can hard-code the version of nixpkgs to use to a non-registry path while still pinning it to a specific commit.
Rather than shell aliases, I’d probably use a wrapper script that pre-processes args. Nushell has nice features to do that ergonomically.
Upstream support for a feature like this would probably be negotiable once the high-level design is figured out, I’d encourage you to write a wrapper script like this and maybe an RFC with the exact behavior if you want it.
All that said, if your concern is a disk space constraint, you probably shouldn’t be using flakes altogether. There are so many misfeatures that just needlessly balloon your disk usage, nixpkgs input duplication is probably only a fraction of that.
2 Likes
Stable* Nix. There’s nothing “legacy” about the option that has & continues to work while not requiring experimental features be enabled. Building hacks/workarounds is always going to be brittle—&, as others are suggesting, if you reframe your basis from “how to make this work with Nix flakes” to “how to make this work with Nix”, your solution might just pop out a lot simpler & still compatible (if not more so if not exposing your flake’s outputs for stable Nix consumption). This could be a reasonable pivot to make if you are grinding too hard against flakes’s purposefully rigid design for what you would like to accomplish as classic, stable Nix is flexible enough to accommodate what you want to do.
2 Likes
Agreed, sorry. I usually try to avoid “legacy” in this context, especially given that I am actively trying to find workable alternatives to flakes that do not lock me out of 90% of the currently existing ecosystem.
3 Likes
I think an official (please don’t let everyone create their own alias it breaks interoperability) wrappers like flake-with-current-nixpkgs may help in quick & dirty usage, but it has many issues:
- Again it does not solve the problem of composability: projects involve other non-nixpkgs dependencies and this won’t solve at all my application #2 since every project would require different parameters, so there is no command to run them all.
- They actually break reproducibility: running
flake-with-current-nixpkgs, updating the system, and runningflake-with-current-nixpkgsagain may fail if updating the system breaks the project. I want breaking changes to involve a volontary action like upgrading the project as it was the case with the old method. - You can still forget to use this variant.
Still curious to know what’s wrong with my proposed design to improve flake.
So maybe we should improve flake instead of creating thousands of flake-like alternative to help with composability and eventually just spread the community and decrease composability? Just to name a few: niv, devenv, Devbox, npins, flake-parts, paisano, flox, std nix… when will we stop? Unless the goal is to create space for commercial products indeed…
Yes, agreed. There are plenty of opposing opinions about how to do so, and by today at least 3 subtly different implementations of flakes. Outside if DetNix they will never become stable.
Any improvement for one will mean a regression to someone else.
Flakes can be burried as they are, or used as they are. Its just these.
2 Likes
I agree. Flakes have become a political minefield being released in the state they are/were where it is unlikely any improvements can/will actually be made—not to mention the manifest file isn’t versioned so it’s tricky to migrate any proposed improvements. & this is before we mention that now all the Nix forks are taking flakes in incompatible directions (see Markdown on how an incomplete spec can pulled in multiple, incompatible directions as features keep getting tacked on all claiming “just Markdown” but don’t work together).
IMO, what would be better an alternative spec/schema that isn’t tied to the Nix binary at all. This would be much easier for tooling to work on & much easier for its community to iterate on. It’s also fine to have a couple of different competing specs too since communities can build adapters for between competing specs. These schemas wouldn’t have the same lockout @NobbZ mentions as some flakes projects that are much less composable since a) follows is weaker than overlays (hinted in this thread), & b) instead of properly using import in the flake.nix to keep the packages, modules, shells, overlays, etc. modular & available stable Nix, folks are putting everything in the flake.nix which is not easily reachable. Tools like nix-run are a step in this direction.
1 Like
Yeah, and there is currently nilla doing something, I do some experiments in my own lab, and there are other people playing in the shadows.
1 Like