We didn’t have the setup for people to both seriously discuss proposals and implement them timely. This is different now that there is this team.
Breaking things apart should help parallelizing the work
@infinisil: What does it mean to finalize something? We should consider Flakes as an experiment that’s widely used but not properly designed. However we could fix those issues in a backwards compatible way after stabilizing.
@fricklerhandwerk: Concrete proposal: get funding for that split work. There is just a lot of work that we agreed has to be done but we collectively don’t have time for.
@edolstra: Disagree this would be much work. Barely any implementation changes needed.
@fricklerhandwerk: There may or may not be much to change in the code, but to solidify and if necessary refine the design we’d need RFC-style (not necessarily full RFC process) decision making, weighing the alternatives and considering long-term costs
@tomberek: What would be the minimal requirements for declaring Flakes stable?
Defining stable as “no backwards-incompatible changes”
Can we support it indefinitely without regreting it?
For instance, if we have an impending change to the lockfile format, should we wait for it?
(some discussion on whether we should uphold the value that Nix expressions shall be reproducible indefinitely for stable features)
(the team silently agreed, @infinisil raised some objections and counter-proposals)
@fricklerhandwerk: Doesn’t prevent us from working on uncontroversial things at the same time. We all seem to agree that we want the limbo state resolved as quickly as possible, the question now is how exactly.
Possible blockers for stabilisation:
flake-schemas extension: needs decision on blocker or not
extension can be added later, does not need to break flakes
also there are still many open questions, so it’s to some extent design work that may or may not advance predictably
a month here is simply unrealistic. we’re already busy with CLI stabilisation and only make slow progress with that. right now we’re adding at least 4-5 new items that will require a lot more than one session to deal with.
(added in writing) we have no evidence that timelines ever worked here, we just do too many things concurrently and without schedule
for timelines we’d need a known amount of developer time available and an estimate of the effort; we have neither
locking mechanism: (clarify?)
What’s the behavior of nix flake lock? Are transitive lockfiles taken into account? Should it be pluggable like @lheckemann suggested?
likely part of CLI+flakes review, and part of the lockfile semantics issue above
call-flake.nix interface: add overrides/follows to API
Mixing two formats in a file like this is an extremely weird idea. Especially since this is not human readable data, and any format can encompass the data of the other. You even show how this could look like in plain JSON in the second code snippet, so why require writing a parser instead of using that directly?
I totally agree, it looks weird but I feel like that’s the only sane option.
most data formats are relatively slow to parse and are very verbose. JSON is pretty fast but at least in the case of lock files - it is not very readable and solving git conflicts is a massive pain
Also, may I add that we are having an issue in nixpkgs with npm lock files due to their size and the fact that they are constantly changing. While this does not entirely solve the problem - it heavily alleviates it
We haven’t exactly agreed yet about how to proceed overall, but I’m sure there will be room to go into these details. There are enough people interested in that and you can start working on it already. Maybe just open a repo following @infinisil’s pattern to discuss larger issues where a design document is the desired outcome: https://github.com/NixOS/rfcs/pull/138