Exposes too much for newer users is a fair assessment for how to improve the UX/DX that makes sense to me.
I’ve also have had some success just teaching people how to use nix without needing to change the way nix currently works 4 times now. It can be done. It does take some time and education. I’ve been either leading or a part of introduction of nix to larger groups of developers in addition to directly using it.
I’m guessing what’s worrying a lot of people is the feeling Det Sys is trying to push the issue towards a close, given the announcements, blog posts and commentary over the last week or so. I don’t think this discussion would have blown up now if that hadn’t happened.
I think there’s a flipside to this, too: the SC election was intended to end prior to NixCon, and got dragged out a bit due to the CIVS issues. So, we’re in the awkward position of having the only place to complain being into the void for a bit when the only sensible time to announce things is around the conference.
I disagree, I don’t see that NixCon should be a hard point where announcements have to be made.
Also, if DetSys truly is a separate company from the NixOS project, why does any election within the Nix project affect what they plan to announce?
I hear you and I understand that the intention here is to avoid unnecessary conflict, and I share that. However, telling people to simply “relax” does not address the more profound issues that have led us to this point. Many in the community have felt pressured to keep their frustrations to themselves, whether due to fear of retribution, being labeled as “causing drama,” or simply wanting to avoid conflict. Over time, this silence has led to a build-up of unspoken grievances, and those tensions are now understandably boiling over.
If we want to build a better Nix community, we must create a space where everyone feels comfortable speaking honestly without fear of backlash. This means creating an environment grounded in respect, where every voice feels valued, including those of gender and sexual minorities and individuals from every background of life. Everyone, regardless of their identity or experience, should feel heard and respected here. Ignoring or dismissing frustrations only allows them to fester. We need open and genuine conversations where respect is non-negotiable, and we must face these issues head-on instead of hoping they will disappear if ignored.
The reality is that we have lost many valuable contributors, especially from minority groups, due to the ongoing drama and the lack of transparency in addressing these issues. This is a significant loss for our community, and if we are serious about building a better future, we need to actively work to regain these individuals and rebuild the community’s trust.
I am working on this myself, trying to be better at listening to others and responding respectfully, even when we disagree. I think we should all make this effort. At the same time, we must be clear in addressing those whose intent is to disrupt and cause harm. Bad faith actors have no place here, and we need to take action to ensure they do not undermine the inclusive environment we are striving to build. We must welcome those who are here in good faith, while being firm in removing those who are not.
Sorry for the mini-essay here. Just wanted to get my thoughts out there. :3
It doesn’t, but that was the short way of acknowledging some of the other pieces of the problem: a lack of points of contact and assertive leadership. That will go away in a couple weeks, but diving into that seemed mostly off topic for this thread.
In my opinion:
nixOS is not a complete, declarative system without flakes.
You can’t call it declarative if the place you get all the software is imperatively defined
Yes, there are other ways to solve this problem, there is like npins and stuff, but having a common interface for 3rd party packages is an essential thing for tinkerers to be able to quickly create and distribute packages in their own repos, and have people actually know how to use those packages, and I feel flakes do a good job of this
I think that they could maybe use lazy fetching of inputs or dev inputs that arent always fetched, but it is entirely possible as is to simply put a second flake in a subdir for running tests and dev shells to avoid the issue of having extra inputs. So this is not really a blocker. Maybe being able to do some logic with builtins in there would be cool too, but again, not a blocker.
Im in favor of making flakes stable. I think the only way for them to be pushed forward further is by taking them seriously. While other ways of managing nixpkgs channel dependency declaratively exist, they dont have the aspect of the shared interface, and so many things support flakes that at this point, going back doesnt make a ton of sense.
I’m also generally in favor of flakes eventually becoming stable, but you can’t just decide that they’re stable all of a sudden (which DetSys tried to do in a blog post last year). You have to actually address the technical issues people have with them, and as far as I can tell there has been little to no effort to do so.
Im not so sure about this. DetSys did try to do that yes. But if a PR gets accepted into nix tomorrow that enables the flag by default, it is now stable. I think people are misunderstanding what the word stable means in software. There can be technical issues in a stable release.
Flakes havent really changed that much since their addition. If we want to ACTUALLY make changes to them, Im ok with them staying experimental. But it doesnt seem like there are any major design changes that would warrant needing to wait to make them stable being proposed outside of dev dependencies, (which are already only a second choice to lazy-fetching and wouldnt be required if lazy-fetching was implemented).
Reminder that you don’t need flakes for declarative config…
My problem with path-based nix is that it is impure, it will look at channels, it will read envvars, and it will read absolute paths all over the filesystem.
I don’t want flakes, I want pure eval in a nix implementation. Unfortunately, the status quo is, if you want pure eval, you must also take flakes, it’s a package deal.
Can pure eval be possible without flakes? Yes! But no one implemented it yet.
in any case the aim of the Nix Team should not be product development for the masses but rather library development for use by other components of the ecosystem
As a newcomer (I already maintain some packages but I’m using NixOS since less than a year), while I agree with the fact that nix should provide a good library for use by other components, I disagree with the fact it shouldn’t also be a good product with a nice interface.
I’d even say the latter is a priority over the former. As a newcomer, the cli interface is quite difficult to grasp, the channel thing seems not powerful enough, fetchStuff is awkward and these push you very quickly into flakes’ arm.
If we look elsewhere, their exists some package ecosystems where the community uses one and only one tool and seems mostly happy about it (rust and cargo for instance). The default experience should be good, even nice (I’m in no hurry though, I can wait for the governance being sorted, just saying ;-))
I am aware, and I mentioned that in my comment, but I also mentioned how flakes still solve problems the other non-flake options do not.
what is npins plus --pure
If normal nix plus purity was what you wanted you would have what you want already
Flakes ARE a pure eval nix implementation. Do they have a rough edge here or there? Yeah, but the ones that exist can be fixed in a non-breaking manner. So they should be adopted properly, so that all contributors know they can focus their efforts without them being wasted.
The general nix team and contributors all treat changes to flakes as if they were making changes to existing stable software because everyone uses them
So, it really doesnt make a ton of difference. They kinda already ARE part of stable, despite not technically being enabled by default.
All you need to do to pretend they are part of stable is add extra-experimental-features “nix-command flakes” or whatever to your build script in your custom installer ISO
and then you literally never need to interact with the fact that they are not technically stable yet.
Making them part of it by default changes basically nothing. So it should be done to save everyone the headache.
but it is soooo nice and simple to use! at least for any small scale project:
put your inputs into the flake
type one single command
profit!
never encountered any “fundamental flaws”
But I don’t know what problems arise on big projects with nix, never participated in those.
I’m a small man, I just want to nix flake lock and nix flake update
(post deleted by author)
Usually this is stuff like, “I need dev dependencies that I dont want my users to need to download and dont know that I can just make a flake in a subdir to use for that” or “I dont know how to properly manage the system variable”
But there are some things that make flakes a little slower?
Outside of that, Im not super aware of any such issues and I would like a clarification myself.
I would not be using nix if not for flakes. I might have tried it out, but without them, I would not still be using nix. I might be trying guix rn. But, at least with flakes, nix is just… its so good…
these are some of the problems flakes were meant to solve and they do a fairly good job of solving them
The original interface being bad does push you to using flakes.
But thats not due to like, the original interface purposefully pushing you to use flakes. Thats because the original interface didnt have answers for a ton of stuff, and flakes DO have answers for those, and those answers are easier and better implemented than other similar options. Thats why I say, nix is not complete without flakes.
As an enthusiastic Nix user since 5 years, that’s not yet contributed that much to upstream projects, here’s my “outside” view on this:
My assumption is that the NixOS Org has people in charge of making decisions on topics like this. Flakes have been around for almost as long as I’m using nix, and no decision has been made on them, which makes me question if the NixOS Org is even able to make decisions. I’m in no way meaning this disrespectfully here, I really love what you people do and I’m enormously grateful for all of it, but isn’t that something that should be already resolved for a long, long time, if everything in the Org worked the way it should?
I think Nix is currently lying to users by saying Flakes are experimental. It doesn’t look like someone is willing to make breaking changes to it, or to even remove it. So if that’s not gonna happen, why aren’t they stable?
If you ask me, I have no problem with doing breaking changes to flakes, or even remove them. Flakes have a lot of problems after all. BUT: Flakes is the best thing we currently have, and as long as the “successor” to them is not ready (or even on the horizon), I’ll use them. Even if it’s moved out of Nix entirely.
But I’ll happily migrate to the successor as soon as it’s here.
This I think is the crux of the issue.
People already treat them as stable because they are the best we have and they have been around a long time
But people also dont fully rally around them because they are not stable.
If they were made stable we might even see more changes being made to them than when they were unstable, despite them being unstable for so long specifically to allow them to be changed.
I am hopeful that the new changes of installing an actual board will fix this. I just hope the people chosen make actual decisions.
Direction is good. Do we want them, or not. Decide. If not, we NEED a replacement, because what we had before was not good enough.
In my book, flakes are good enough. Could they be better? Yeah, but most of the things Ive heard being proposed to make them better have been either, A, non-breaking stuff about inputs, B, trying to say we should have a module system like flake parts be built in as part of flakes, which I strongly disagree with, as I feel like it increases the barrier of entry by too significant of a degree. Flakes should be simple, a wrapper for your modules or packages that imports stuff and has an accepted output format. If you need extra complexity in them, go for it, but they are at a good mix between functionality and simplicity as is by default.
So, unless we wanna implement the flake-partsy versions of flakes as the new redisigned flake version and make everyone convert, we should make it stable, as all commonly proposed improvements that arent basically flake-parts-by-default that I have heard of are non-breaking.