Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC 0049] Flakes #49

Closed
wants to merge 42 commits into from
Closed

[RFC 0049] Flakes #49

wants to merge 42 commits into from

Conversation

@edolstra
Copy link
Member

@edolstra edolstra commented Jul 15, 2019

Abstract: This RFC proposes a mechanism to package Nix expressions into composable entities called "flakes". Flakes allow hermetic, reproducible evaluation of multi-repository Nix projects; impose a discoverable, standard structure on Nix projects; and replace previous mechanisms such as Nix channels and the Nix search path.

Rendered

@samueldr
Copy link
Member

@samueldr samueldr commented Jul 15, 2019

How will "channel advances" be published with flakes?

Flakes are looked up in a registry that maps identifiers such as nixpkgs to actual locations such as github:edolstra/nixpkgs/release-19.03. You can use such locations ("flake references") directly in the nix command:

Let's modify the location in the example to nixpkgs/release-19.03 (is this valid?). Will end-users need to somehow know that they should be using nixpkgs-channels/nixos-19.03 to get the tested channel advance?

If the "tested update" publish workflow is a branch on the main (nixpkgs) repository, it will become possible for contributors to accidentally push an untested, maybe even invalid, branch to the repo. Not a great idea.


Additionally, an orthogonal point.

Flakes replace channels [...]

I'm assuming this will be part of "Hammer out the details of NixOS/NixOps support for flakes", as this reduces a bit the reproducibility, if it isn't used in conjunction with nix flake pin when upgrading the system. Otherwise, rebuilding the system after a channel advance will produce a different system, instead of the expected no-op.

Copy link
Member

@FRidh FRidh left a comment

The RFC is well written. I do think we should aim at getting answers to the unresolved questions. I think the proposed direction is good from a usability point of view, and to get a bit of order in our expressions.

rfcs/0049-flakes.md Outdated Show resolved Hide resolved

Flakes are motivated by a number of serious shortcomings in Nix:

* While Nix pioneered reproducible builds, sadly, Nix expressions are
Copy link
Member

@FRidh FRidh Jul 16, 2019

Mention how pure evaluation mode fits in and if/why that is not sufficient.

rfcs/0049-flakes.md Outdated Show resolved Hide resolved
GitHub archives, we cannot directly check that the contents match the
commit hash.

Note that lock files are only used at top-level: the `flake.lock` files
Copy link
Member

@FRidh FRidh Jul 16, 2019

Consider the situation where one wants to offer a package set consisting of stable third-party applications, where each application is defined in a separate Flake and has a lock file to guarantee its reproducibility. In that case the lock files of the applications are ignored, no longer guaranteeing the stability of the applications.

The idea of not considering the lock files is good in case of libraries, but in case of applications not always.

Copy link
Member Author

@edolstra edolstra Jul 16, 2019

Yes, good point. We could simply always use the lock file of a dependency if it exist (so good practice would be not to commit lock files for library flakes). It gets tricky for flakes that provide both libraries and applications (like Nixpkgs)...

Copy link
Member

@ryantm ryantm Jul 16, 2019

This seems like something to consider carefully or it could become a big pain.

Copy link
Member

@ryantm ryantm Jul 16, 2019

I'm not sure I understand the difference between packages and apps, but what about having whether a lock file is considered be based on which set the reference is in?

Copy link
Member

@FRidh FRidh Jul 16, 2019

I think also that when a lock file is present, it should be used. It basically says "we provide a curated set, don't break it". It's then up to the community to ensure they don't use it incorrectly.

Now, in practice I think that is not something we cannot always rely on and so we want to be able to override/patch. Also, because upstreams tend to pin things too much; just look at the amount of patching we need with Python applications. We are given the attributeinputs, which is already imported, and won't allow us to override or patch the Flake when needed which, if correct, is a limitation.

Copy link
Member

@Profpatsch Profpatsch Jul 16, 2019

We’re discussing things here that many other systems have stumbled over in the past.

Copy link

@hlandau hlandau Jul 20, 2019

Lockfiles shouldn't be committed to repositories under any circumstance, unless it is a distribution repository. This is no different to vendor bundling, which is rightly opposed. It's for a distributor to decide how to combine dependencies.

I agree that lockfiles in dependencies should be ignored. If this principle were abandoned, it should be strictly opt-in.

Could someone explain why lock files in dependencies should be ignored? Doesn't it break the reproducibility of evaluation if the inputs of the dependency got updated?

Copy link
Member

@shlevy shlevy Jul 29, 2019

Without care, there is a tension between flakes offering composability on the one hand and reproducibility on the other. Ignoring dependent lockfiles is one way of reducing that tension: The flake.nix should specify the interface for the flake (eventually with version bounds or similar?) and the flake.lock should specify the current composition for people working on that project directly.

For example, I'd like us to eventually have a stdenv flake that abstracts out the bootstrapping logic and definition of mkDerivation from nixpkgs proper. When I'm developing on stdenv itself, I want some fixed definitions of things like gcc etc. so I have something to work with, but the entire point is that I ultimately want the caller to specify these! So when nixpkgs imports the stdenv flake, it should provide the pieces that make it all work.

Copy link
Member

@Ekleog Ekleog Jul 30, 2019

Maybe it might make sense, for a first draft, to say “lock files in dependencies are a hard error for now” and to just add that as a to-be-resolved-later question?

I'm not sure we need what @FRidh wants right now (and it's something that apparently only makes sense for applications, so not that well-explored for build systems at least), and this way is forwards-compatible with any future road we might end up choosing for handling lock files in dependencies.

rfcs/0049-flakes.md Outdated Show resolved Hide resolved
rfcs/0049-flakes.md Show resolved Hide resolved
rfcs/0049-flakes.md Outdated Show resolved Hide resolved
"id": "import-cargo",
"inputs": {},
"narHash": "sha256-mxwKMDFOrhjrBQhIWwwm8mmEugyx/oVlvBH1CKxchlw=",
"uri": "github:edolstra/import-cargo/c33e13881386931038d46a7aca4c9561144d582e"
Copy link
Member

@FRidh FRidh Jul 16, 2019

While understandable for Nix, these uri's are still a bit odd for other potential consumers. Is there a reason for not putting a concrete https url to a tarball here? I suppose to be able to still use git after all. In any case, the motivation seems to be missing.

Copy link
Member Author

@edolstra edolstra Jul 16, 2019

It's because the github: scheme has some particular caching semantics, in particular using the fact that the ETag returned by GitHub is the Git revision. We can't assume that for https tarballs in general.

Copy link
Member

@alyssais alyssais Jul 16, 2019

We should come up with a better name for this scheme, then, and make it so the full URL is still included. I don’t think Nix should be coupled to GitHub (and as proposed this wouldn’t even work with GitHub enterprise). If we used attribute sets instead of URLs, this could be an attribute in the set.

Copy link
Member Author

@edolstra edolstra Jul 18, 2019

Hm, why wouldn't it work with GitHub enterprise?

There is definitely something to be said for attrsets instead of URLs, but it means that we would have different syntaxes for flake references on the command line and in .inputs.

Copy link
Member

@alyssais alyssais Jul 19, 2019

Well, there’s no way to specify the domain GitHub is running on.

The command line is a good point. Could just be multiple arguments, maybe?

Copy link

@hlandau hlandau Jul 20, 2019

IMO, the best option here is to abandon the github: scheme and specially recognise URLs of the form https://github.com/... as supporting an alternate retrieval strategy. The advantages of this would be:

  • Separation of what is retrieved from how it is retrieved; github: and https://github.com/... are the same what, just being retrieved via a different method. But an URL is supposed to specify the what, not the how.
  • This avoids having to change github: URLs if the retrieval methods GitHub supports change.
  • Conversely, suppose some other hosting site https://example.com/ becomes popular in the future. If you want to add a more efficient way of retrieving Git repositories, with this model you'd be asking them to change to example:... to do so, which would break compatibility with older versions of Nix which don't understand example:....

Copy link

@toonn toonn Jul 28, 2019

Shouldn't it be up to the user whether they want to use https or something else? Similar to how you get the option to clone using https or ssh in the github interface.

While a URI does indeed merely identify a resource a URL definitely most commonly specifies a protocol to be used for the retrieval. So I'd rather see a scheme where git://github.com/... is valid than having https urls being subverted non-obviously.

Copy link
Member Author

@edolstra edolstra Aug 16, 2019

IMO, the best option here is to abandon the github: scheme and specially recognise URLs of the form https://github.com/... as supporting an alternate retrieval strategy.

Special-casing certain HTTP URLs seems much uglier than having a separate URI scheme. You would expect all resources in a particular URI scheme to be interpreted uniformly.

Also, from a UX perspective, having to figure out / type https://github.com/edolstra/patchelf/archive/master.tar.gz (and hoping that that's the special URL recognized by Nix) is worse than github:edolstra/patchelf.

Copy link
Member

@alyssais alyssais Sep 27, 2019

Special casing would be a very bad idea, because GitHub URLs don’t support all the features of git URLs. Like many other things in this rfc, I think we should be asking ourselves “is this feature absolutely critical for an initial release?” The answer to me in this case is quite clearly no. So I propose we drop GitHub URLs for now, in favour of git URLs, pending further, more focussed discussion.

Really late, but couldn't this quite easily be solved with something like github:(customdomain.com)edolstra/patchelf?

zimbatm and others added 2 commits Jul 16, 2019
Co-Authored-By: Frederik Rietdijk <freddyrietdijk@fridh.nl>
Co-Authored-By: Frederik Rietdijk <freddyrietdijk@fridh.nl>
rfcs/0049-flakes.md Show resolved Hide resolved
rfcs/0049-flakes.md Outdated Show resolved Hide resolved
rfcs/0049-flakes.md Outdated Show resolved Hide resolved
rfcs/0049-flakes.md Outdated Show resolved Hide resolved
rfcs/0049-flakes.md Outdated Show resolved Hide resolved
rfcs/0049-flakes.md Outdated Show resolved Hide resolved
rfcs/0049-flakes.md Outdated Show resolved Hide resolved
rfcs/0049-flakes.md Outdated Show resolved Hide resolved
@edolstra
Copy link
Member Author

@edolstra edolstra commented Jul 16, 2019

How will "channel advances" be published with flakes?

Let's modify the location in the example to nixpkgs/release-19.03 (is this valid?). Will end-users need to somehow know that they should be using nixpkgs-channels/nixos-19.03 to get the tested channel advance?

Ideally, we would merge nixpkgs-channels into nixpkgs. The only reason why we have a separate channels repo is to prevent people from pushing channels, but nowadays GitHub allows per-branch access control. So we can restrict these branches to a team that only includes the channel update script.

So nixpkgs/release-19.03 would refer to the untested 19.03 branch, while nixpkgs/nixos-19.03 would be the tested one.

I'm assuming this will be part of "Hammer out the details of NixOS/NixOps support for flakes", as this reduces a bit the reproducibility, if it isn't used in conjunction with nix flake pin when upgrading the system. Otherwise, rebuilding the system after a channel advance will produce a different system, instead of the expected no-op.

Yes, exactly. The idea is that your NixOS system is itself a flake, so its flake.lock pins the exact version of Nixpkgs. FWIW a NixOS configuration flake looks like this:

{
  name = "eelco-configurations";

  edition = 201906;

  description = "My NixOS configurations";

  inputs =
    [ "nixpkgs/nixos-19.03"
      "dwarffs"
    ];

  outputs = inputs: rec {

    nixosConfigurations.my-server = inputs.nixpkgs.lib.nixosSystem {
      system = "x86_64-linux";
      modules =
        [ ./configuration.nix
          inputs.dwarffs.nixosModules.dwarffs
        ];
    };

  };
}

which would be built by nixos-rebuild using

# nix build --profile /nix/var/nix/profiles/system ~/Misc/eelco-configurations:nixosConfigurations.my-server.config.system.build.toplevel

rfcs/0049-flakes.md Outdated Show resolved Hide resolved
rfcs/0049-flakes.md Outdated Show resolved Hide resolved
rfcs/0049-flakes.md Outdated Show resolved Hide resolved
rfcs/0049-flakes.md Outdated Show resolved Hide resolved
@lheckemann

This comment has been hidden.

@aanderse
Copy link
Member

@aanderse aanderse commented Jul 16, 2019

@edolstra Am I correct in assuming that this will fix the issue where every machine in a nixops network is locked to the same channel?

Copy link
Member

@Profpatsch Profpatsch left a comment

What I’m missing most from the current version is a prior work section with how other package managers solve this problem and how it has influenced the design of flakes. Especially the design of flakes’s lock files.

There’s been much practical research in that area over the last few years.

packages.dwarffs =
with inputs.nixpkgs.packages;
with inputs.nixpkgs.builders;
with inputs.nixpkgs.lib;
Copy link
Member

@Profpatsch Profpatsch Jul 16, 2019

It’s probably cleaner to a reader not in the know of nixpkgs if those are aliased instead of pulled in with with.

Copy link
Member Author

@edolstra edolstra Jul 18, 2019

Hm, what do you mean with aliased?

Copy link
Member

@Profpatsch Profpatsch Jul 19, 2019

Just something like:

let
  pkgs = inputs.nixpkgs.packages;
  inherit (inputs.nixpkgs) builders lib;

rfcs/0049-flakes.md Outdated Show resolved Hide resolved
rfcs/0049-flakes.md Outdated Show resolved Hide resolved
rfcs/0049-flakes.md Outdated Show resolved Hide resolved
rfcs/0049-flakes.md Outdated Show resolved Hide resolved
rfcs/0049-flakes.md Outdated Show resolved Hide resolved
rfcs/0049-flakes.md Show resolved Hide resolved
rfcs/0049-flakes.md Show resolved Hide resolved
rfcs/0049-flakes.md Outdated Show resolved Hide resolved
rfcs/0049-flakes.md Outdated Show resolved Hide resolved
Copy link
Member

@alyssais alyssais left a comment

I’m extremely wary of this. I don’t think that Nix should become a package registry, and I am extremely concerned by the lockfile issues others have raised. In particular, what should happen when dependencies pin to different versions of Nixpkgs, and the inability to patch flakes due to them not being exposed as derivations. I think it’s imperative that this RFC should not be merged until we have satisfactory solutions to these issues.

On the other hand, some things in here excite me a great deal. I love the syntax this will enable for the nix cli, for both pinned and unpinned versions. Channels and default.nix both have their own rather severe shortcomings, and I’m looking forward to seeing the back of them. This strikes me as an extremely complicated solution to that problem, but perhaps there is no simple one…


There are multiple registries:

* The global registry
Copy link
Member

@alyssais alyssais Jul 16, 2019

Why do we need a global registry at all? Could we not just, eg, provide hard-coded defaults for nix and nixpkgs, and let users do the rest? This would avoid becoming a package repository to any extent, which I think would be a very good thing.

@alyssais what would the defaults be?

Copy link
Member

@alyssais alyssais Jul 18, 2019

Maybe

  • nix = https://github.com/NixOS/nix stable
  • nixpkgs = https://github.com/NixOS/nixpkgs unstable

Copy link
Member Author

@edolstra edolstra Jul 19, 2019

We don't need a registry, but it seems important for UX. In fact it's more important here than in tools like Cargo, since the registry is used in a command line interface. We don't want to require people to type nix run github:NixOS/patchelf instead of nix run patchelf. Special-casing nixpkgs seems ugly, and it makes every other flake second-class compared to nixpkgs (which is bad since we should move away from the monorepo approach since it doesn't scale).

Copy link
Member

@timokau timokau Jul 20, 2019

which is bad since we should move away from the monorepo approach since it doesn't scale

I disagree here, which is probably also the reason I'm a bit hesitant with the flakes approach in general. For me the monorepo approach is one of the major selling points of nixpkgs. Probably the selling point. It lowers the barrier to contribution a lot. It makes it very easy to find any information I want with a single grep. I can bisect any problem. I can test if my update breaks any known reverse dependencies. There is a central point of trust, even if that trust is very diffused at the moment.

I imagine a bunch of single-package repos loosely tied together with lockfiles will actually scale less. Why would I want patchelf to be in its own flake vs. in nixpkgs?

Copy link
Member

@alyssais alyssais Sep 27, 2019

crates.io works very well so I don't think a registry needs to be a disaster. In any case,you don't have to use the registry. Of course then you have to type things like nix build github:NixOS/nixpkgs:... instead of nixpkgs:... all the time.

You could have the same ergonomics with a local registry only, with the nice commands for adding to it proposed in this rfc, though, with none of the need for us to maintain any sort of global registry.

Copy link
Member

@alyssais alyssais Sep 27, 2019

Ultimately however the monorepo approach fundamentally doesn't scale: it shouldn't be necessary for everybody who just wants to share a NixOS module to have to add it to the nixpkgs repo.

I don’t want to argue this further in this thread, because I think it’s off-topic for the RFC, but I want to make clear that I still don’t agree and any such move would need to be discussed extensively at a later date before it were to happen.

Copy link
Member

@spacekookie spacekookie Oct 29, 2019

crates.io works very well so I don't think a registry needs to be a disaster. In any case,you don't have to use the registry. Of course then you have to type things like nix build github:NixOS/nixpkgs:... instead of nixpkgs:... all the time.

You mentioned crates.io a lot in your NixCon talk and it's obvious that this RFC took a lot of inspiration of what Rust is doing. I'd like to chime in here that the public often doesn't see a lot of the effort and sweat that it takes on parts of people to run crates.io, and the architectural problems that it comes with. This doesn't just include the actual infrastructure and the team of people it takes to run it, but also a lot of policy decisions on things like DMCA requests, name squatting, etc that introduce a lot of work that general users of the service aren't aware of either. It's easy to say "look, it runs really well" and not see the weekly meetings on policy updates. I got the feeling that everybody involved in developing NixOS was already pretty booked out. I feel that adding yet another thing to maintain to the list of NixOS infrastructure things would be an extremely bad idea.

Copy link
Member

@spacekookie spacekookie Oct 29, 2019

The crates.io ecosystem is fundamentally a different maintenance approach to NixOS. There are no "Rust maintainers". Sure, there's people who work on the compiler or who are active in various working groups and teams (👋) but there's no centralised development in the way that NixOS requires it. Building a bunch of libraries is different from building an operating system distribution and while a global registry of libraries works well for one, it wouldn't scale at all for the other because it's the same people involved in most of the pieces. It just adds overhead.

Copy link
Member

@spacekookie spacekookie Oct 29, 2019

Re: the mono repo

As others have said previously, the fact that all the moving parts in NixOS are in a single place, can easily be bisected and tested against one another is a huge selling point for collaboration and also lowers the barrier to entry. NixOS is the first Linux distribution I've actually started working on, despite wanting and very much trying to get involved in both Debian and Fedora. I think it would be a shame if this were to change.

There's a relevant discussion/story from the Rust/ rustc repo about this. The repo itself is huge, unwieldy, takes ages to download etc. So it was proposed to remove certain components from it that are only tangentially related to the compiler core, such as rustdoc. Ultimately, it was decided to keep the repo as it is, because rustdoc is a component that frequently breaks with new PRs and so, it's common practise that if a compiler contribution breaks docs, that person then also fixes docs.

I think you could compare the development of rustc with the development of NixOS/nixpkgs. They are both mono repos, both part of an ecosystem with moving pieces around it, but strongly integrated i each other and benefit greatly from having all their parts kept in the same place.

rfcs/0049-flakes.md Outdated Show resolved Hide resolved
rfcs/0049-flakes.md Outdated Show resolved Hide resolved
rfcs/0049-flakes.md Outdated Show resolved Hide resolved
rfcs/0049-flakes.md Outdated Show resolved Hide resolved
@andir
Copy link
Member

@andir andir commented Jul 7, 2020

I still do not see how

On the meeting we discussed leftover concerns (cross compilation, versioning, etc) and have decided it's
future work.
Acceptance of this RFC doesn't mean flakes are in the final form, but that we're happy with initial version
and there's a way for people to play with flakes as experimental feature under the current specification.

is compatible with the current writing. It doesn't contain the word "Experimental" or even that it is not in it's final form. Let me quote, from this repo's README.md, again:

In general, once accepted, RFCs should not be substantially changed. Only very minor changes should be submitted as amendments. More substantial changes should be new RFCs, with a note added to the original RFC. Exactly what counts as a "very minor change" is up to the RFC Shepherd Team of the RFC to be amended, to be decided in cooperation with the RFC Steering Committee.

IMHO if the RFC would agree, with what appears to be the outcome of the RFC meetings, I'd be fine with accepting it. If the description in the README.md is wrong, or doesn't align with our views, we might consider changing that. The RFC process has to evolve if it doesn't cover what we need. It isn't set in stone but in (all) our hands.

Also, as expressed earlier, the examples given in the current "specification" are not working anymore. We should try to have at least the initial version "working" at the time of acceptance. To some degree those should be good examples of how flakes help. Them being broken doesn't help. A good review of this RFC should contain trying the examples since we have a prototype(?) implementation already. How else do you really review this document?

Note: I do not agree or disagree with the technical flakes implementation anymore. I just want the process to be properly executed.

@michaelpj
Copy link

@michaelpj michaelpj commented Jul 7, 2020

Moving to a constraint-based approach (where the system finds a composition that satisfies the constraints, rather than having the user specify the composition) would be a pretty fundamental change to Nix's model.

I'm not talking about inputs for individual derivations, I'm talking about flake inputs. We could have flake versions and constraints without touching how normal derivations work.

(You might think it seems strange to endorse versions and constraints for flakes but not for derivations. Maybe it is: but at the moment I care more about flakes, derivations seem to work okay as they are.)

@edolstra
Copy link
Member Author

@edolstra edolstra commented Jul 7, 2020

Also, as expressed earlier, the examples given in the current "specification" are not working anymore.

RFCs are not a final specification or end-user documentation. As the README says: "We strive to write each RFC in a manner that it will reflect the final design of the feature; but the nature of the process means that we cannot expect every merged RFC to actually reflect what the end result will be after implementation." The goal of the RFC process is to get agreement in broad terms on a proposal, not to nail down every detail.

A good review of this RFC should contain trying the examples since we have a prototype(?) implementation already. How else do you really review this document?

Not true since RFCs don't require an implementation.

@toonn
Copy link

@toonn toonn commented Jul 7, 2020

While the latter part might be technically true. Announcements about the RFC getting accepted might prompt people to check it out and maybe try the examples. So unless it's a lot of effort to update the examples wouldn't it make for a much better first impression if they worked out of the box?

@domenkozar
Copy link
Member

@domenkozar domenkozar commented Jul 13, 2020

@edolstra @alyssais @shlevy @Ericson2314 as per my previous comment, I'd like to ask you to vote if we accept the RFC.

@shlevy
Copy link
Member

@shlevy shlevy commented Jul 13, 2020

I agree with the above comments that the RFC should clearly state the experimental nature of the functionality.

@alyssais
Copy link
Member

@alyssais alyssais commented Jul 13, 2020

@Ericson2314
Copy link
Member

@Ericson2314 Ericson2314 commented Jul 13, 2020

As I recall it, the concensus in the last meeting was that:

  1. Experimental features don't require RFCs

  2. We do not concensus on what the final form of flakes should look like in, or perhaps even roughly what it should like

  3. It's best best to try to reach it empirically, via the unstable feature.

  4. Some people wanted to merge the RFC (amended to make the above clear) anyways. The rest had no objection.

So the main thing I care about is seeing the flakes implementation merged (after final review) so this saga doesn't stay in uncomfortable limbo where no one is happy.


The RFC process was not written with experimental features in mind, which is fine with me. Once the RFC is amended to clearly state the experimental nature of the flakes, I think we will be in conformance with the letter of the RFC process. Even the issues raised post FCP can technically be construed as non-blockers as the RFC effective becomes a referendum on whether to have a flakes experimental feature and not what the feature's final form is. That all is perhaps not in the spirit of the RFC process, but that would not be a violation that concerns me because the stakes are low.

I am OK with merging the RFC, provided it's amended to clarify the experimental status. I am also OK not merging the RFC because we don't need an RFC.


For those still concerned about process and norms, that NixOS/nix#3744 was opened and then closed makes me a lot less worried that experimental features will become de-facto stable. This is good news!

@cab404
Copy link

@cab404 cab404 commented Jul 15, 2020

Is there any documentation on flake output names? I didn't find anything about "defaultApp", "defaultPackage", "lib", "templates", etc.

You can look at complete list of output types in the code here, but that amount of types makes lack of documentation (or at least code comments) even worse.

@edolstra
Copy link
Member Author

@edolstra edolstra commented Jul 16, 2020

Experimental features don't require RFCs

Yes, good point. Flake support has been merged into master now (NixOS/nix#3573) as an experimental feature. We can keep this RFC open and update it to reflect future changes, or close it now and reopen it at some point.

@andir
Copy link
Member

@andir andir commented Jul 16, 2020

May I propose to just close this RFC and opening another one once we have a final proposal that isn't experimental? The value of accepting this document in the current form is questionable (to me). The discussions here are probably good (valid) input for the continued experimentation with flakes up to a point where it could be called stable. At which point we shall have another attempt at an RFC?

@edolstra
Copy link
Member Author

@edolstra edolstra commented Jul 16, 2020

Yes, sounds good.

@Mic92
Copy link
Member

@Mic92 Mic92 commented Jul 25, 2020

Since this RFC is not extensive enough to be used as documentation and the nix repository also does not provide any except for the source code I started writing a wiki article: https://nixos.wiki/wiki/Flakes

@arianvp
Copy link
Member

@arianvp arianvp commented Jul 25, 2020

@bqv
Copy link

@bqv bqv commented Jul 25, 2020

This is still an experimental feature

@arianvp
Copy link
Member

@arianvp arianvp commented Jul 25, 2020

@Mic92
Copy link
Member

@Mic92 Mic92 commented Jul 25, 2020

Why not make those docs part of the nix manual?

On Sat, Jul 25, 2020, 11:16 Jörg Thalheim @.***> wrote: Since this RFC is not extensive enough to be used as documentation and the nix repository also does not provide any except for the source code I started writing a wiki article: nixos.wiki/wiki/Flakes — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#49 (comment)>, or unsubscribe <github.com/notifications/unsubscribe-auth/AAEZNI3KE6RMCM7GE3VBTGTR5KPHFANCNFSM4ID3SJCQ> .

docbook... and I am not sure if those PRs are accepted.

@Ekleog
Copy link
Member

@Ekleog Ekleog commented Jul 27, 2020

Having a link to the wiki (that makes it very explicit it is an experimental feature) as part of the manual might make sense, I'd personally be wary of having the docs for experimental features that are expected to change alongside the docs for regular features — taking example on Rust that has an unstable book in addition to the regular (stable) rust book would seem like a good idea to me.

@Mic92
Copy link
Member

@Mic92 Mic92 commented Jul 27, 2020

Having a link to the wiki (that makes it very explicit it is an experimental feature) as part of the manual might make sense, I'd personally be wary of having the docs for experimental features that are expected to change alongside the docs for regular features — taking example on Rust that has an unstable book in addition to the regular (stable) rust book would seem like a good idea to me.

The wiki has has now a complete reference on the nix command: https://nixos.wiki/wiki/Nix_command
This allows to link to new commands as well as extending examples. I also started fixing some examples that are currently broken in --help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment