Nix Team Creation
discourse.nixos.org
discourse.nixos.org
However, if I can't find what I need in the documentation then it can be a problem. That's specially true for installing software. I'm not too familiar with the language to make entire new packages. Most things are using flakes and I haven't wrapped my head around them yet. Other things are not really compatible with its philosophy (like software packaged as Wine bottles).
Nix itself: same problem when the package doesn't exist. But when it does, it's wonderful. I'm even using it in OSX, instead of homebrew (with home-manager).
Hopefully this team will help smooth some of the rough edges.
With flakes, it is now significantly easier to create an standalone package or module for your specific needs since you import it just like nixpkgs. It also means that software doesn't have to be part of nixpkgs to be usable on the system - if a git repo has a flake it's just a matter of adding it as an input. Flakes represent such a massive improvement to the way that you interact with nix, I sincerely hope they become the default here soon. In the meantime, it is well worth your effort to learn them even if they aren't 'required' yet.
Unfortunately all of this is contingent on being able to grok the language in the first place which is where the documentation really falters. The nix pills talk about the basics of the language but it is very difficult to make anything useful without importing some libraries (i.e. nixpkgs) - and these libraries are not very well documented. I am aware of a documentation team being formed to help address this but it still remains the number one issue with nix, especially for newcomers. The unfortunate thing is that there are so many moving parts that it will take a considerable effort to explain the entire ecosystem without being overwhelming but still providing enough intuition for newcomers to get things done with Nix.
If anyone is interested, a recent SoN talk was given about efforts to improve the documentation. It touches on many of the things I bought up here: https://www.youtube.com/watch?v=WFRQvkfPoDI
As for keeping up with PRs and other responsibilities, that seems to be one of the stated goals of the this new Nix Team. I guess we'll see how they intend to handle this soon.
If we split things up, there will be less open PRs per project of course. But I doubt the ratio will be much better. It will actually increase the number of PRs as large scale refactors will be multiplied by the number of repositories.
As for flakes, they're not that big a change. There's some entry point which you have to learn about - a special file (flake.nix) that defines inputs and outputs according to some predefined structure. But the output leafs are just normal nix code - it's just that there's some builtins that can't be used because they do side effects at runtime. But that's less important than it sounds, because if you're using nixpkgs (as a library/input or as a source for copypasting) then it's flake-safe.
https://github.com/Gabriella439/haskell-nix
and for nix in general this recent tutorial:
I always wondered why there are no wine packages using nix. Sure, it is likely not legal, but I would absolutely love to have an MS office package that mandates a specific hashed file (that I can torrent and add to the nix store - this way I don’t even risk viruses), and the install itself is deterministically done (perhaps with some headless GUI clicking here and there).
Edit: fixing autocorrect typos.
(So AIUI a tiny fraction of the available software. Still, it's not nothing.)
> the code replaces my notes entirely.
I think this ends up being one of the key selling points for Nix for developer machines.
I'm blown away by what Nix/NixOS has accomplished without having a formal team in place. Kudos to the maintainer(s), community and best wishes to the new Nix Team.
The old development style mentioned reminds me of that excessively mentioned essay about Lisp hackers keeping to themselves. I wonder if there's something intrinsic to certain developer-oriented projects like these that lead people to tinker with them on their own for long periods of time.
What is Nickel? Is this an officially endorsed project? It’s run by Tweag — do they run Nix? Most core contributors work for Tweag. What is the fate of the Nix language? Should I start investing in this new language?
Why is documentation still so bad? Why is there not a clear and official answer to documentation generation? Syntax linting? Testing? Who is in charge of trying to fix SEO for documentation?
Nix is technologically sound but is struggling organizationally from its explosive growth
In this case, "it's experimental" should be read as "maybe the team will decide to make changes", rather than "it's not going to work half the time".
e.g. one change they made was changing the property "defaultPackage" to "packages.default".
(Anyway, the UX improvements from flakes are good, that once you've got the boilerplate, flakes are amazing).
> Nix is technologically sound but is struggling organizationally from its explosive growth
Well, that's the opposite problem of 'floundering'.
In that case, I can't in good conscience recommend we use such a feature at my workplace. We can't afford huge breaking changes, which is what that flag suggests. Which means my workplace is stuck with a bunch of `shell.nix` and `direnv` magic instead of clean flake-based envs.
It's not enough to gate features behind a flag, unless your only audience is enthusiasts. Versioning your features makes them accessible to a wider audience and encourages more risk-averse folks to adopt the features despite the possibility that they may undergo slight changes.
just pin the nix package itself and that should ensure the flake API remains consistent for however many months/years you want?
This is true of literally any dependency, though.
Semver is supposed to grant you confidence that things won't change very much, but it's not a technical guarantee.
In terms of "risk of adopting nix flakes", the lion's share of the risk is in "adopting nix" (because nix is difficult, hard to find people well versed in nix, etc.). The risks from adopting flakes on top of that are marginal.
> Which means my workplace is stuck with a bunch of `shell.nix` and `direnv` magic instead of clean flake-based envs.
if flakes win out, this other stuff might well be deprecated someday. timeline for that is probably lengthier than the timeline where flakes don’t win, but it’s still there. in either scenario you’re gonna have a month or more between one approach being deprecated and being dropped altogether (6 months if you’re on the stable channel). you’re implicitly betting for or against the success of flakes here, weighted by the cost of refactoring should you bet on the “losing” side plus maintenance until the winner emerges. you describe non-flake maintenance as being higher cost, so from the outside it just feels like a suspicious bet to make.
That kind of circular reasoning seems problematic.
Don't get me wrong, I like flakes, I use them for my NixOS setup, but the way that flakes development has been handled is very concerning.
You sound like you have something particular in mind.
If I look at the Nix RFCs, flakes was as RFC 0049 https://github.com/NixOS/rfcs/pull/49
Maybe Alyssa's comment here? https://github.com/NixOS/rfcs/pull/136#discussion_r987278726
+1. The explosive growth has resulted in organic blossoming of several new ideas, approaches and templates. Not all of them are great and it takes time to sift through them to see if there are canonical approaches.
The creation of the team to streamline these ideas, bless some official paths is well timed.
> In this case, "it's experimental" should be read as "maybe the team will decide to make changes", rather than "it's not going to work half the time".
This I think is part of the problem. People see the "experimental" label and don't understand that it's not "experimental" in the sense they're used to. Maybe labeling flakes as a "beta" feature and featuring the documentation more prominently would ease the confusion.
This is exactly the clarification that needs to happen. It hasn't yet, and we've been needing it. That's what I mean by "floundering". Nix isn't broken, but its development progress has been needing explicit direction and clarity.
That's why I'm excited to hear a team is being put together. This is a great opportunity to bring some decisiveness into Nix's development.
But in terms of contributions, capabilities, and userbase, the Nix lately been subject to impressive and exciting growth that you mention. I think the best is yet to come, but it's already fair to say that Nix is flourishing.
The community and the codebases also do have growing pains, of course. But I don't think that Nix is floundering at all.
(And yes, I absolutely agree that if we could go back in time and change it to pretty much anything else that would be better.)
That's the opposite of floundering, no?
I'm not close enough to Nix development to know whether this is the case or not in this instance, but the Discourse post makes a compelling argument about pull request statistics. Sibling commenters also point out that flakes have become a de facto standard despite being hidden behind an experimental flag, suggesting that the flag has lingered too long and without clear ownership or authority around stabilizing the feature. That indecision feels like floundering.
It felt like that to me for a really long time, in between the releases of Nix 2.3 and 2.4, when there were lots of features being added but there was no release schedule. The divide between flakes users and non-flakes users was also larger then, as the feature was gated behind not just an experimental flag, but pre-release versions of Nix.
Since then, Nix has gotten into a regular, fairly rapid release cycle and new functionality is released pretty often. There are various concerns about what that change does and doesn't fix for Nix, but for me at least there's no longer that feeling of stagnation or mystery about when Nix will see a stable update released.
> flakes have become a de facto standard despite being hidden behind an experimental flag, suggesting that the flag has lingered too long and without clear ownership or authority around stabilizing the feature. That indecision feels like floundering
Flakes have been conceived and pushed forward by the original author and chief maintainer of Nix. In the earliest stages of their development, consensus proved difficult to build and the community RFC process was very young. Suspending that RFC and adding the features to the master branch but marking them 'experimental' was an attempted compromise on the part of Eelco Dolstra, who had previously more or less taken a BDFL approach to maintaining Nix.
Since then, the flakes implementation has matured quite a bit. I think most users expect that it will evolve into an official feature soon and without many fundamental changes, although some community members still feel some bitterness about that initial process as well as skepticism about the scope and necessity of the whole suite of features that come with flakes.
At the same time, many RFCs have gone through the process since then. The organization of the projects and processes for getting ambitious changes approved are much more explicit now. In those ways, it's clear that leadership/governance in the Nix community is becoming more organized and more effective.
it gives me hope. I just wish the boilerplate were less arcane. Nix is a relatively elegant language, I'm not sure why nixpkgs is so ugly.
(One guesses they have software dev jobs and will have some % of time dedicated to that).
I thought Nix is the ecosystem?
nixpkgs is the ecosystem, since it contains all the packages.
Other important parts of the NixOS ecosystem include:
- NixOS, the main module system which adds many configuration management capabilities to Nix
- Nix-Darwin and home-manager, extremely popular module systems for using Nix for configuration management on other operating systems
- various deployment tools: NixOps, Hail, Colmena, deploy-rs, Terranix
- pre-flake version pinning tools like Niv
- flake libraries like flake-utils, flake-utils-plus, std, and flake-parts
- development environment utilities and libraries like devshell, Lorri, and integrations like those of direnv and shadowenv
- the Nix User Repository and various important overlays (e.g., the Emacs overlay, the Rust overlays)
- the many 2nix conversion tools, some of which are chiefly distributed outside of Nixpkgs and used to package things in private or company collections rather than in Nixpkgs
- arguably some proprietary commercial products and SaaS offerings, like Cachix, Hercules CI, and Flox
- the NixOS hardware profiles collection
- the Nix and NixOS manuals
- important unofficial documentation sources, like nix.dev and nixos.wiki, and even important blog series like the Nix Pills or Ian Henry's reading of the official documentation
- wrappers and developer applications based on Nix, like devboxes and nixpacks
- GUI tools for working with Nix code or configuring NixOS, graphical app stores, etc.
- editor integrations like rnix-lsp, nix-mode, and environment management plugins for various editors
- a couple of really cool tools for automatically creating portable/deployable shell scripts with Nix (binlore + resholve)
- tools for generating magic fat binaries based on container technologies, like nix-bundle
- partial reimplementations of various parts of the Nix stack for specialized use in other programs, or sometimes aspiring to compete with Nix (like tvix)
(And of course leveraging Nix successfully doesn't mean one has to evaluate or learn all of these tools. Most users will organically discover and stick with just a handful of them according to the demands of their own use cases. But in total, there is a really wide landscape of Nix-based and Nix-related software out there.)