I don’t appreciate your accusations of bad faith here.
2 Likes
Wow, what a long thread. Could it be split?
I’m not feeling well today, but I’d like to share a few thoughts on the original topic. I’ll have to save the rest for later.
- Nix is an open source project. Be the change you want to see.
- Flakes stabilization has been discussed at length. See RFC 136 among other discussions. Not fast enough? Refer to (1)
- Regarding priorities, other changes that aren’t flakes, etc, refer to (1)
The Nix team has put a lot of effort to make (1) possible.
Do something positive today. Doesn’t have to be Nix. Thank you 
57 Likes
Related to being more positive, I’d like to propose that any discussion of this kind of thing be values-first in the future so actual decisions can be made.
“We prioritise project health over individual interests” would have been an interesting discussion as long as “We treat each other with respect and civility. No matter one’s individual identity, circumstances, level of contribution to the project, or status, everyone has the right to respect, and everyone has the duty to treat others with respect” and “People with higher visibility within the project or towards the public are subject to higher expectations for their conduct” were followed as well.
The pathway to having these discussions be civil is right there and we should follow it.
10 Likes
In light of that: does anyone know if there is an effort to fast-track the formalization of locking, without pulling in the rest of flakes (yet)? A more generic version of flake.lock, with perhaps a discussion around version ranges and dependency resolution (upon which flakes can then rebased transparently)? Moving hashes out of .nix files is probably one of the most liked, least controversial topics, so it could be useful to address that head-on. Particularly if backwards compatible with flake.lock.
Is there an RFC / discussion for this? My google skills aren’t up to par 
8 Likes
just my two cents, but looks like flakes already got some momentum. In PR terms abandoning them feels absolutely terrible.If people invested in them and like them they might feel cheated if the flakes suddenly gone. And I don’t think average user is going to dig deep in the architectural decisions behind this - before it worked, now it doesn’t.
Could some alternative be implemented? Based on niv or similar project? Maybe even with some silly name and not in the official repo so it doesn’t even need experimental flag? With modular design and purity and dependency resolution, and what not. Now if the new solution is happen to be better we name it “flakes 2.0” and sell it as improvement. If not we abandon the whole thing (and nothing gets worse than it is now).
Also could someone explain how exactly flakes place burden on the whole team? I thought that they are not even in the nixpkgs, Couldn’t people just ignore them if they see them as conceptually unfit for purpose?
4 Likes
If there would be some new iteration of flakes (or another solution altogether) that is as newb-friendly as flakes, I’d have no problem switching over to that. But on the other side, many may not be so eager to re-engineer their configs.
2 Likes
You will notice that 90% of the noise in this thread is drive-bys with no skin in the game. The people actually doing the work are less than 1% of the posts.
8 Likes
Sorry to say this so directly: your position sounds like the 1% who are doing the work should not listen to the 90% who are downstream consumer’s of that work. If you really believe that downstream consumers have “no skin in the game”, then the game being played is arguably self-absorbed.
If that truly were to be the case, we might have made a big step towards identifying the root cause of the problem.
4 Likes
Yes, that is true. But that is to be expected. The majority of users are not the ones writing the code. Yet they are the ones who have the knowledge you need to tap into to sanity-check your work. Unless you are only writing code for yourself.
So it’s to be expected that the people bickering are not the ones writing the code. And my point is, moreover, that it is good to listen carefully.
You might say this entire thread only exists because there was a similar thread a year ago. And the situation hasn’t really decisively been resolved.
Do not put words into people’s mouths. Miss me with that bullshit.
I said your position sounds like not you said. So do not ascribe stuff to me that I didn’t do.
But you’re right on the other thing, I should have replied to your message specifically, not the entire thread.
Edit: Now your post as been flagged while I was writing this. Well…
4 Likes
Cool. That might well be true. It has nothing to with me or my post. I was responding to someone complaining that the people writing the code / nix experts were wasting their time on discourse. I have absolutely no opinion that is worth sharing about who should or should not be listened to.
That’s fair.
1 Like
lazy trees are in the works still, and are not a breaking change, thus are not a reason to not make them stable.
1 Like