[RFC 0096] Experimental Nix derivations

[gytis-ivaskevicius]

Rendered

[Ericson2314]

I don't thunk unstable features should be too easy to use. We already have enough governance controversy around flakes as it is.

[Ma27]

Also even an experimental release would IMHO send a wrong signal: given that there's still no actual flakes RFC (or any kind of standardization process) I'm not very confident that the interface will remain as-is, so having even more people relying on this is IMHO a bad idea (to be clear: I personally think the premature promotion of Nix 2.4 we currently experience is a bad idea in general).

[mweinelt]

I don't thunk unstable features should be too easy to use. We already have enough governance controversy around flakes as it is.

The joke here is, that unstable features are already too easy to use, seeing the number of flakes users bleeding into our primary support channel.

[lovesegfault]

This RFC comes off as very low-effort. Partial list of questions that should have been covered:

• What's the motivation?
• What are the trade-offs?
• Is there precedent for doing this? Maybe prior art in another project or within Nix itself?
• Are we okay setting this precedent, if it doesn't already exist?
• How do we communicate clearly to users that it's an experimental feature with no guarantees?
• If this doesn't go well, is it easy to revert course?
• Is the cost of manually enabling flakes high enough to warrant this? Is this something worth fixing?
• What do we lose if we don't do this?

What's the point of submitting and RFC if you're not going to use it to explore the problem space?

[gytis-ivaskevicius]

The whole motivation of this is that quite a few peeps very much liked the idea but it ended up being shot down.

Flakes are already quite easy to use, hence peeps who use Nix even for a little while start moving their configuration over to Nix 2.4.
But there is a good reason for that - even in terms of most generic use-cases Nix flakes makes life so much easier. All the Nix flakes-specific projects are just a bonus.

I personally think the premature promotion of Nix 2.4 we currently experience is a bad idea in general

Could be so, not going to argue If it is a good or bad idea but aside users promoting flakes - pretty much all the articles that exist on flakes either avoid noting that it is an experimental feature or like tweag give out something that looks like a weak warning.

Package name nixUnstable makes it sounds like a "rolling release of Nix". And I am sure that I am not the only one

seeing the number of flakes users bleeding into our primary support channel.

Assuming that they are reporting actual bugs - I do not think that it is a bad thing. If it really is bothersome maybe some separate space for such issues should be created.

TL;DR: I strongly doubt that additional lines in nix.conf is a deal-breaker for anyone who gets shilled into using Nix Flakes.
But what we can do is better communicate that this is an experimental feature, preferably while improving UX.

[gytis-ivaskevicius]

@lovesegfault Sorry about the lack of answered questions. Could not really think of much to note there. I Will update it, as well as the whole format of this RFC

[gytis-ivaskevicius]

Generified and expanded on the topic.

[nrdxp]

I am quite in favor of this proposal. I may not have the right perspective here but to me it seems, so far, that every proposal to improve flakes is shot down immediately. If this doesn't get approved, then it may be better for the community to just remove flakes all together if you don't want some way for users to try them, and give feedback.

Otherwise the message being sent is very confusing. Should we use them at all? Should we expect for them to be removed? How can they be improved without real world user feedback? Do you even want them to be improved, or are they being phased out? At the very least we need some sort of official communication on these topics.

We definitely need to stop the sensationalism being generated in places like this twitter account.

[Ma27]

Note: I'm in fact such an early-adopter which means that I use it for e.g. my private deployment and a few side-projects (but for no customer stuff though). Yes, I do believe in flakes in the mid-term, but I also see a lot of weird, unaddressed issues (such as segfaults during evaluation) and a lot of uncertainty in how it will look like in the end. I still remember that e.g. one idea for another iteration was to use TOML as config-format which would essentially mean that one has to rewrite all of their configs. This is why I wouldn't want to recommend it to the average Nix(OS) user (or even beginner).

How can they be improved without real world user feedback?

User-feedback is obviously a good thing, but the obvious trade-off is that - well - people must be ready to test it. And my impression is that it's way too early for a community-wide feedback round for the reasons I mentioned above in this comment. Also, testers have to be aware, that flakes aren't really battle-tested, so the experimental-features is a fair way to warn them.

At the very least we need some sort of official communication on these topics.

Agreed! IMHO we need a roadmap and some sort of standardization process (such as an RFC) for it where every community-member has a chance to participate and actually provide feedback to core-concepts of flakes.

As soon as this happens, I'll reconsider my strict "I don't recommend flakes"-policy because then I hope that I'll become more confident that it has reached a testable & usable state for an average user (or is about to do so). I mean, I consider myself a power-user who can work with all of this despite its uncertainty which is why I'm testing/using it already :)

We definitely need to stop the sensationalism being generated in places like this twitter account.

I've always interpreted it as satire-account (perhaps because I don't think a platform with a length-limit of 280 chars per post is a good way to discuss things) and while satire usually has a truth in its core, it also works with exaggeration.

[maljub01]

In my opinion, reverting that change was the right call.

Instead of the proposed change here, why not modify the nix derivation to make it easy enough for an end user to override it by specifying a set of experimental features they want to be enabled.

I am pretty sure this is also pretty standard because I remember for example overriding "vim" to make it include some extra stuff.

That would also mean nixFlakes would no longer be special since you'd be able to get it by overriding nix with experimentalFeatures = ["flakes"] or something like that, which would be nice.

[blaggacao]

While I was not in favor of the initial proposal, I'm strongly in favor of the reworked proposal because it features a prominent warning (improvement over status quo) and a link to a dedicated resource that gives more context on the current and maybe future state of flakes (improvement over status quo).

Some of the counter-arguments center about "not making an experimental feature too easy". With the above additions to the reworked proposal, the author has converted this objection into a strength.

One disadvantage of the current proposal is that feature flags (of which there are more than just flake related stuff), are no more exposed to the user as individual feature flags. I think this is a drawback in transparency (disimprovement over the status quo).

@maljub01 's proposal to make it easy to provide a set of feature flags as an override seems to me like an appropriate venue to improve this RFC further in light of possibly entering a FCP.

Such final proposal would detect the presence of (those easily setable!) feature flags and show warnings and links to further context accordingly. Initially for the flakes feature flag.

I have a sense that a lot of people do not very conscientiously set those feature flags because they are set and forgot in some "obscure" (from a flake perspective) config file. It would be a significant improvement to incentivize people to start "purely" declaring the behaviour of nix.

With such modifications, and with the current state of ideas, I think any future Shepherd Team should deem this RFC viable.

[gytis-ivaskevicius]

I very much liked the @maljub01 idea of overrides thus I updated RFC accordingly :) And turned out that I became very excited about the idea of a website as part of the warning. And believe that feature status handling as such would be super neat due to the increase of visibility and I would dare to say that it is a sign of community maturity.

Also, this idea could be expanded to release schedules and maybe even other GitHub Projects

Anyways, any thoughts from the downers?
Would be cool if you guys were to review this RFC and note any objections if there are any.
\CC @jtojnar @Ericson2314 @Ma27

[jtojnar]

Implicit enabling of features was what I had an issue with so I retract my downwote. I am split about whether making the experimentalFeatures config more accessible is a good thing.

For comparison, web browsers also had this issue and they ended up with experimental flags in hidden settings too: https://css-tricks.com/is-vendor-prefixing-dead/ https://developer.mozilla.org/en-US/docs/Glossary/Vendor_Prefix

[Ma27]

Even though I still disagree with the approach (as stated in the comments below - I'm happy to be proven wrong though), I understand where it comes from.

However, to me this seems like another attempt to fix the symptoms:

• I'm not sure who mentioned it first (so sorry for not giving credit), but the few resources we have about flakes don't make it clear that it's an experimental feature in the first place. For instance, Tweag's first blog-post about flakes calls it "a new Nix feature" in the first sentence, so I think I understand why people can misunderstand this (another reason would be that e.g. Hydra requires Nix 2.4 these days for instance).
  In other words, I like the idea of having a rather official website explaning the state of Flakes (whether or not it's linked in a hypothetical eval-warning).
• For NixOS releases, we have a release-team (with at least one RM), a blocker-project and a time-window when a release is planned (yes, delays do happen, but one can at least estimate when a new release is there). For Nix I'm kind of missing this sort of transparency and roadmap. The thing is, I don't really know what I'd write on such a website because I don't know if the current APIs are stable or not (and if not, what will change). And stuff like "flake's format could change" won't be too helpful if somebody wonders whether to try Flakes out. That said, I already raised the question in BoehmGCStackAllocator: ignore stack protection page nix#4264 (comment) whether we may need a Nix core-team (which was disbanded in RFC0044) again since the steering committee is responsible for RFCs affecting the NixOS project in general rather than Nix-only changes.

[blaggacao]

Also, this idea could be expanded to release schedules and maybe even other

At this moment, I want to leave it to the author's consideration to rename the RFC to better match the "set of goals" over "the implementation details" after the recent rework and incorporation of various feedback.

[nrdxp]

I was just thinking, as a viable alternative, we could simply make the function of flake-compat an official nix subcommand on stable nix installations with a patch version bump, thereby allowing stable nix users less frustration when finding a flake.nix. (by making all expression therein evaluable [in theory 😄])

[gytis-ivaskevicius]

I beleive we are ready for nominations. I propose @nrdxp @blaggacao @Ma27 @jtojnar @maljub01. Are you guys up for this?

[spacekookie]

Opening this RFC for nominations. Can nominated shepherds please respond whether they accept?

[edolstra]

Nominating myself.

[nrdxp]

I'll accept the nomination as well

[maljub01]

I accept the nomination.

[blaggacao]

I accept the nomination.

[edolstra]

We have the following shepherds: @edolstra (leader), @blaggacao, @maljub01 and @nrdxp. Thank you all!

@gytis-ivaskevicius Do you think it would be useful to have a call about this RFC with the shephers?

[gytis-ivaskevicius]

Yeah, I and @nrdxp were talking about it like 20min ago :D Will create a channel on matrix and invite everyone over

[edolstra]

Summary of the 2021-08-05 shepherds meeting:

• We can add a compile-time setting to Nix to enable experimental features by default (e.g. a configure flag like --with-experimental-features="nix-command flakes").
• This would allow providing a nixFlakes binary (with installer script) that has flakes enabled by default.
• The installer script for such a Nix binary should warn that experimental features are enabled.
• Possibly we should also print a warning if an experimental feature is enabled at compile-time but not in nix.conf.
• Currently experimental features are undiscoverable and undocumented. It would be nice if there was a way to query what experimental features are available in a Nix release, and to get some documentation about them (like a link to an associated RFC).

[blaggacao]

Addendum from the meeting:

• The reason for providing a nixFlake binary and not any arbitrary experimental feature binary could be that flake are some notion of a "beta" feature, in practice, although there are currently no official terms (yet) to describe any notion of feature graduation. (See k8s feature stages for further inspiration.)

[edolstra]

@gytis-ivaskevicius Do you want to update the RFC to reflect the results from the meeting (#96 (comment))?

[gytis-ivaskevicius]

Sorry fellow nix'ers, but these days I don't have time for pretty much anything which is why I am closing this RFC. Let's just wait till flakes becomes stable