The Nix project has grown a lot in the last couple of years. It is seeing ever more adoption, and the ecosystem around it keeps expanding. However, for many users and contributors, there is a lack of clarity about the direction of the project. This is partially because project goals are not always clearly communicated, but it’s also because there not always is a clear direction, and different people have different ideas about where to take the project.
To improve this situation, we want to establish a roadmap that communicates to the Nix community where we want the Nix project to go in the future. The roadmap includes both technical goals (e.g. stabilizing flakes) and community/social goals (e.g. empowering Nix teams). […]
Scope: This is a roadmap for the overall Nix project, i.e. everything under the nixos.org umbrella: the Nix package manager itself, the Nix language, NixOS, and so on. The individual project teams (e.g. the Nix or NixOS teams) can have their own finer-grained roadmaps.
The roadmap is not a general wishlist, and should address significant problems faced by Nix users.
Timeline: The roadmap should consist of goals that are realistic and likely to be worked on. So feature requests that have nobody interested in working on them should not be on the roadmap.
Process: …
(copy from the Nix vision PR?)
(for each theme: why we’re doing it, and what is needed to accomplish it, and maybe how you can help?)
Why: nix lacked hermetic evaluation, an easy way to compose multi-repository Nix projects, and a standard interface to Nix-based projects that enables discoverability
flakes solve this
flakes have been around for a couple of years now, but are still marked as experimental
however they’re widely used now; there are thousands of projects on GitHub with a flake.nix in them
the uncertainty surrounding the experimental status of flakes is cited as a major concern by many (potential) Nix users
What is needed: We have sufficient experience with flakes now to officially stabilize in essentially its current form, i.e. without breaking compatibility. Thus, the main thing to do is to create an RFC to remove the experimental status of flakes. At the technical level, flakes had trouble supporting large repositories, but work on fixing that is nearly complete. The new nix CLI has been in wide use and can be declared stable once flakes are stable. At that point, we can release Nix 3.0.
Flakes currently have a number of problems that we can address after Nix 3.0, in particular the lack of a way to customize flake outputs such as packages from the command line.