I see npins being proposed as the de facto solution to the ‘flakes problem’, but one thing I rarely see anyone address is utilizing npins in a multi-machine, multi-input setup for personal systems. Most examples I’ve found use it as a saner way to manage project inputs and development environments, but beyond that, I haven’t seen much discussion related with more personal setups.
My personal flake has grown into a fairly complicated monster, and I wouldn’t mind optimizing it. However, I haven’t found a similar setup that had private flake-based inputs containing various variables and shared configurations that are then consumed by the primary flake.
Correct me if I’m wrong (I’m still learning of how flakes works in general, coming at this from the perspective of a someone just using the tool everyday), but does npins even allow this sort of ‘nesting’ of flake inputs?
What are you asking about here? Managing your system configuration and managing a development project are exactly the same when it comes to input pinning. What are you not able to reproduce with any other pinning solution that flakes allow you to do?
You may be interested in following Looking for setups/blog not using flakes although I’m not sure someone has yet replied with an exact answer for what you are asking.
In particular, if consuming private flake-based inputs is critical for you, then yes the most natural way to consume a flake is to use another flake. There is GitHub - NixOS/flake-compat · GitHub as a shim if non-flakes code really wants to import a flake as a flake.
Alternatively, many repos that package themselves using flakes also have a default.nix, package.nix, module.nix, etc that may serve as a reasonable entry point instead. This is very repo dependent.
In general, I think that if flakes didn’t exist then structuring a default.nix as a function is a natural way for nix to express inputs and outputs. The function args are the inputs, and the output is a single attrset containing all the outputs.
Your experience is your own, but in my experience, people frequently like to claim that systems without flakes are not reproducible, because otherwise nixpkgs is defined using channels. This inevitably annoys people who understand
Flakes are also typically using channels, they just aren’t using nix-channel to define the channel outside of the configuration repo. If someone uses releases.nixos.org/channels.nixos.org, inputs a channel tag on the nixpkgs github repo, or uses pre-built packages on cache.nixos.org; they are using channels.
If the claim is that the critical difference between flakes and stable is pinning, then there are other methods to achieve pinning
npins is just one very popular solution to the pinning problem, for which there are also builtins, nixtamal, yea, pinch and others. It is not a solution to all of flakes and I can’t comment on whether people have actually been proposing it as such.
In fact, flakes combine pinning, conventional/standardized schema for inputs and outputs, pure evaluation (which implies copying full source tree to store and necessity to define system explicitly), limiting certain parts of the Flake to “trivial” subsets of nix, de facto ties to git through the implementation (instead of allowing more general choice of source control), de facto ties to Github (as opposed to more general support for other source control forges in flakeref schema), nix3 conveniences (some of which are available without flakes), etc.
I think one of the big issues is that some people may consider certain parts of this integrated whole to be anti-features. Anyone who wants exactly the flakes experience will just use flakes. Anyone who doesn’t will find solutions for just the subset (pinning, schema/composability, tooling, pure eval, etc) they are actually interested in.
The main thing I’m confused about with npins was the fact that it’s not having a flake.nix at all; I use direnv to load up my flake’s devshell to initialize git and some ssh variables (useful for when I’m reinstall my flakes from the NixOS isos). What would I use instead of a flake.nix?
The easiest is a shell.nix file, which contains the same expression that you’d assign to devShells.<system>.default. And then use use nix with direnv instead of use flake
Ah yeah, I can see how that’s be annoying (especially with tying the schema directly into Github, given the serious infra downtime they’ve been having lately ). I have ran into some of the annoyances related with trying to get the flake to look at my private repo (especially as I’ve been moving everything over onto codeberg).
The best outcome for Flakes would be to be to be removed from all Nix implementations and broken out as a separate project that could be maintained by people who actually care about it.
Asking the Nix team to maintain a bunch of half-baked features isn’t good and I’m surprised more people haven’t burned out on it already.
This would mean removing some of the perverse incentives & hard coupling Flakes has introduced, like coupling pure-eval with Flakes.
Pure evaluation is in reality completely orthogonal to Flakes.
It should always have been experimented with as a separate project which could have made Nix better for everyone, including those that have no interest in Flakes.
Yes! I think this is one of the biggest issue with Nix at the moment. Some features have been tied to flakes for no real motivation, besides practicality of the development, I guess.
The most critical is the new nix command since the stable nix-* interface is really old, full of footguns and in dire need of a rewrite. Sadly this used to work without flakes, but at some point became almost entirely flake-only and the non-flake scenarios half-broken at best. There is an effort to untie the new interface and stabilise it, but it’s proceeding at a glacial pace.
Having read the PR comments and proposed change, it doesn’t really look like anything has been rejected, just a comment from edolstra saying that they don’t think it’s a good idea.
I even kind of get where that comment is coming from. Apparently the motivation for your PR is to ultimately decouple nix3 commands from flakes (which I would love and support), but the specific thing it seems to implement is not that. Instead it seems to be changing flakes to have a non-flake.nix entry point. Given that flakes are meant to be a conventional schema, I understand feeling that allowing other entry points than flake.nix would be antithetical to flakes’ design.
This thread isn’t really a good venue for discussing technical contributions, but I’d still like to clarify:
No, pure-eval being bound to flakes isn’t a political issue but certainly just requires design and implementation work. I recommend talking to the team more about that – it’s not a rejection. More of a note that flakeref parsing is certainly not the limiting factor of having pure-eval not be bound to flakes (i.e. mostly about a practical interface - maybe something more capability based interface for source accessing?). If anything, restrict-eval and flakes don’t work together well and we certainly need something more structured and more sound.
I know that this had some input from Robert because that was done at the ocean sprint. When he mentioned it to me I didn’t fully understand the end goal though.
Is there actual disagreement over the proposal to separate flakes out as their own modular part of the codebase rather than having them wired in as the pinning scheme? Yes the details of that ie if that is controversial, but why are we arguing over stability rather than just trying to find anything there is agreement on that we can rally behind to get this behind us. It appears relatively uncontroversial to agree on separating flakes into their own thing so why not motion towards more modularity as an explicit goal. This nicely sidesteps stability concerns as once flakes are sufficiently separated versioning and stability can be decided by those using them.
AFAIK the goal of a SC is to help dictate a direction for the project that should never mean micro managing or calling the shots for other teams until an issue has proven so sticky that it becomes a problem stalling or causing major friction in the community. And I think there is vast community sentiment that this is one such problem. The point of an official SC decision is that we as a community can rally on some direction of action rather than rehashing the same argument every time it comes up, which is what currently happens.
I truly do not care if flakes are stabilized or not, and I suspect it’s an XY problem to some degree for many, we want clarity and stability sounds a lot like clarity but it is not the only way.
Flakes are imperfect, they have very real technical issues around things like supporting cross-compilation easily (IIRC), their introduction did not spark joy. But, nearly 4/5 of the users of nix use flakes.
There are two types of languages, right: the ones people complain about and the ones people don’t use.
Once again, louder, for those in the back:
78% of users use flakes.
This does not mean flakes are good. This does not mean that flakes were introduced in a palatable way. This most importantly does not mean that we can’t improve on flakes in the future.
But, it does mean that flakes are here and in use and we’re stuck with them right now.
If this were a healthier community, we’d quit arguing, ship flakes, and then figure out flakes2 and do it right. Flakes would be a weird little wart that would eventually atrophy and fall off, but that’s our entire industry.
But to get there, we need to actually move on. The anti-flakes people can have their long-term if they can find a way to grin and bear it in the short-term.
(My hot take is that the core problem is that a lot of folks have given up on actual improvements on nix as procedurally intractable or politically impossible–if people thought progress were possible they’d be a lot more optimistic that we could fix flakes later. Flakes are just a familiar example, a symptom of a larger disease where the only thing most people feel empowered to do is snipe at each other and complain about any movement in any direction. Maybe that’s a bigger problem than whether or not flakes suck.)
One of the main reasons I am using flakes, is because I don’t see a clear alternative using stable features that achieves the same goals. Thus I made that post, because I really like to use stable features.
Currently, I prefer the new nix3 cli, as it (on the user side) feels nicer to use. Additionaly while flakes have many quirks, I feel that they currently provide the clearest (as they are so abundant) way to bundle a bunch of dependencies together in a single repo, and provide a number of entry points.
As for now I took the disadvantages (which are very present) for granted (quick ones I can think of are copying to store, not being able to use a single pkgs instance across my system in different flakes, due to individual pinning/purity).
I applaud efforts to decouple the “new” cli from the implementation, I think it could benefit the growth of an alternative.
EDIT: I also want to add that I see a lot of hard work being done on smaller stuff like system.nix, but also bigger thinks lik elazy trees and CA derivativions. Just a honourable mention!
Why the need to rush, as the sentence above states that 3/4 of users are already using flakes? That’d make it seem that it’s not a discoverability issue.
Currently people are aware that the feature is not stable, and they clearly still opt into it. The Nix (and others with a valuable, to me) opinion gave reasons why they’d rather not call flakes stable. That in and of itself seems enough reason to me to stop relitigating this debacle every now and then.
I understand the feeling of wanting to call something stable at some point, but given every reason in this thread, I don’t see the actual need, and can’t seem to find one in this thread so far. I’m curious.
No, stuff like this tends to survive everything like cockroaches (Reading this back, this comes across as overly hostile. I actually like flakes for the most part.). It’s on of the primary way people interface with nix. The idea that it will eventually just go away is unrealistic. Best case it can be replaced with a shim rather than staying a central nix feature.
But yeah the experimental flag should go. Even if the feature is unstable, I don’t think it’s merely an experiment any more.
Since everyone is getting their opinion in, I do wish they were versioned. So, for instance, we could have gradually phased-out compat modes for broken and weird misfeatures, the gradual introduction of schemas, parameterization, and so on. Normal persistent protocol design, in other words, with warnings when someone does something that is ill advised.
Currently, there’s a tension between them being either the platonic ideal of software distribution (ehm… they’re really useful, but not by a long shot) or the most approximate[ly annoying] solution to a somewhat consistent Nix interface we’ve got.
Honestly, I kind of want to do a set of stickers that just says “flakes were discovered, not invented” because of the current situation and of the number of people it might make chuckle.
Since 78% of users already use flakes, that surely does not mean we need to make it easier / more accessible to use them? Clearly everyone or at least most people that want to use flakes have managed to do so, so it can’t be too hard to use them.
I am obvilously being a bit facetious here, but I don’t think usercount is an indicator of what one should do one way or another.
). I have ran into some of the annoyances related with trying to get the flake to look at my private repo (especially as I’ve been moving everything over onto codeberg).
