[edolstra]

It refers to the new CLI, i.e. the "nix" command. The old CLI is the nix-* commands (nix-env, nix-store, etc.). The new CLI and flakes are still marked experimental, but the plan is to stabilize them and call that "3.0". So it won't be very different from the current 2.12 - you just won't need to enable some experimental features anymore to get the new CLI/flakes.

[the_duke]

Do you have an idea when the stabilization might come?

I've been using flakes for well over a year and there doesn't seem to be much discernible progress.

[Macha]

Because of politics (see RFC 49, 134, 136), I don't see this actually happening that soon.

There is agreement in principle to carve out a store only Nix so the no-flakes crowd can build their own UI on it which is held by them as a pre-requisite to any stabilisation of flakes, along with some bad blood of it being announced by blog post. But it's slow because the project maintainer and chief flakes advocate doesn't want to adjust the project just so an alternative frontend specifically to avoid their view of an easier Nix should go ahead.

People are still working somewhat constructively towards this in 134, but because their goals feel fundamentally opposed, it seems likely to go on a while.

[pxc]

The Nix team, including the Nix author and chief developer of flakes (upstream in this thread, so be kind all), is also working right now on enabling the nix3 UI for non-flakes setups as well: https://discourse.nixos.org/t/2023-01-16-nix-team-meeting-mi...

Consensus is hard but I'm glad to see people coming together on this. Really looking forward to seeing the new Nix command and flakes move forward (independently)

[unshavedyak]

Funny i don't want a UI, i just want better type systems so some random field is easily known. I know it's difficult, but strictly from a user experience - that's all i want lol.

[pxc]

I'm really optimistic about Nickel, which is a new DSL based on Nix (in terms of inspiration) and designed for Nixpkgs-like use, but informed by the designs of other DSLs in the same space (e.g., Starlark, CUE, JSonnet).

One of the things it adds over Nix's design is types (it grew out of early efforts to add gradual typing to Nix). It has a gradual typing system with 'contracts' for dealing with untyped code.

I have spent some time doing exercises and examples in it, first in Nix code and then translating it to Nickel. It feels very Nix-y, in the best way, and I think in the end it will be very nice to use.

Definitely check it out if you have thoughts about Nixlang and how it could be better! Development is very active and the maintainers seem quite appreciative of testing and feedback.

https://github.com/tweag/nickel

[unshavedyak]

I've been patiently waiting the nickel<->nixpkgs integration. Several hurdles they have to solve first though, iirc, but yea Nickel looks great.

Really that's almost all of my issues with Nix[(pkgs|os)]. Nickel hopefully solves that quite well.. we just need it to work with Nix first, which is a big hurdle on its own.