Hedgedoc is the FOSS fork/rename of codimd/hackmd. They renamed a while ago. I’d prefer Hedgedoc from a political point of view and actually from a feature set point of view. It sees more development these days.
You can read more about that history here:
This was essentially the second half of my suggestion: i.e. maintain some sort of alternative way of specifying flake shorthands. Perhaps a local registry, or perhaps a config option. In any case, it seems further brainstorming is needed before an RFC is even viable.
Agreed on all 3 points, this could be the lowest common multiple.
Even if anything specific to flakes can be delayed, we should really hash out RFC process for experimental features, as you mention. Simply relying on Experimental tag is not sufficient in Nix, IMO. One of the tweets in reply to @domenkozar 's introspective series of tweets on this topic was that it gets confusing for the masses, as the feature is experimental, but all the cool kids are already using it. It fragments the community and ongoing efforts.
Just wanted to emphasize re: the registries that
There are currently 3 registries on the flakes builds of Nix (user, system, and global)
Registries are just shortnames for URIs pointing to Nix code
Only the global registry, being both built in and unconfigurable, is really any organizationally different from channels, which are also configurable shortnames for URIs pointing to Nix code (and come with Nix if you use the tarball installers)
aside from the global registry, Nix flake registries and the whole nix registry subcommand have no more basis for controversy in them than ol’ nix-channel. So to me, everything but the global registry obviously belongs in the MVP flakes release we’re trying to imagine here
Thanks to @Pacman99 (“eagle eye”), who spotted it and pointed me to it, I guess this is actually less of a problem than I thought, since flake inputs seem to be lazily fetched (not only evaled)..
This is so implicit, that maybe a clarifying conceptualization would suffice.
EDIT: I suggest using an _ prefix to denote local dependencies. For ecample if any library want’s to use nixpkgs and devshell as local deps for the devshell and the checks, we could conventionally import them as inputs._nixpkgs & inputs._devshell.
sorry the interruption
For example, I want to set
XDG_DATA_DIRSto make bash auto completion to work automatically for things in my shell; and similarly I want to have man pages work as soon as I enter the shell (MANPATH).
I have partially implemented this in nix#4702, but seems like upstream is not too keen on introducing such features so far.
However I’d say this is much more related to the CLI redesign and the Installables abstraction than flakes.
Lots of great ideas here. Do we have a any plan of action or Github issue where all this is condensed?
@blaggacao has kicked off an unofficial flakes roadmap for brainstorming a future here
Anyone should feel free to open issues upstream and link them as I did for the inputs.patches idea.
Inlinging source here, since I should not trust the hedgedoc demo server:
Unofficial Flakes Roadmap
=====
You wanted it. Even though, our apoligies, it's unofficial.
In fact this document just takes the gist out of all the feedback from https://discourse.nixos.org/t/improving-flakes/12831.
## What are flakes?
- Flakes are a vehicle to help nix philosophy to gain mass adoption (like snow-_flakes_ falling all over a place).
- They also are a way to promote ecosystem growth through _decentralization_.
- They _enforce_ clear input / output interfaces for an otherwise extremely flexible `nix` language.
- They are a `flake.nix` at the root of a folder tree, written in `nix`, that satisfies [certain contracts](https://github.com/NixOS/nix/blob/e6150de90d8db101209fc6363f5f7696ee8192c4/src/nix/flake.md)
- They are pure eval _by default_.
- They are a whole new class of CLI experience within the `nix 3.0` milestone. — a highly contested item ("solve everything at once")
## Ideas & Discussions
### Super Stupid Flakes (a.k.a. "legacy `nix` isn't going away")
###### Origin of Idea: @zimbatm
##### "✤" represent parts of the contract
Each repo top-level contains a `default.nix` (✤) . The file returns a function that takes `system` (✤) and `inputs` (✤) as attributes and which returns an attrset. That attrset has some reserved attributes like `lib` (✤) , `overlay` (✤) , `devShell` (✤) and `defaultPackage` (✤), and probably more (exact list to be determined).
Each repo top-level contains a `flake.toml` (✤) that contains project metadata. This means the inputs, the project description and the list of supported systems.
TODO: I’m assuming inputs would work the same as in the current implementation.
Turn on pure eval by default.
Restore recurse into attrs.
That’s it.
#### Can I make this backward-compatible?
Yes, use `{ system ? builtins.currentSystem, inputs ? import ./flake.lock.nix }` as the header.
Where `flake.lock.nix` (✤) is a poly-fill that plays a similar role as the current `flake-compat.nix` . There is a possible variant where Nix actually generates the `flake.lock` file so that it can be imported with Nix.
#### Is `lib` getting re-evaluated for each system?
Use the fact that `import` memorizes the result. So for example `{system, inputs }: { lib = import ./lib.nix; }` would return the same lib for each system.
#### Does it cache my eval?
No. It would be nice to cache it, but it can be done later. The current implementation is strictly tied to git and gets invalidated on each new commit.
#### What if I want to build a derivation that depends on multiple systems?
Avoid doing that. It makes it hard for contributors to use your repo as they now need access to all the target architectures and set them up as nix remote builder, to build the repo.
If you really need to, add a separate `release.nix` (✤) file that cobbles everything together. Classic Nix is not going away.
### System as an Input
###### Origin of Idea: @domenkozar
##### This probably was in part a thought-parent to Super Stupid Flakes (TM)
[In his own words](https://www.notion.so/Flakes-system-as-an-input-instead-of-an-output-2d2cdef8eac2434a833d6faae15b35c0).
```toml
[flake]
supportedSystems = [
"x86_64-linux",
"x86_64-darwin",
]
[inputs]
...
This is a psychological one: people not familiar with the nix language arguably prefer a familiar format as the entrypoint.
This idea combines with Super Stupid Flakes
To preemt the “growth through decentralzation” aspect, we also need a way to work smoothly with in-tree sub-flakes to be compatible with out current mono-repo ecosystem model. We need to iron out the subflake experience to offer the best of both worlds and make transition smooth.
flake.nix unlike their language-specific cousins, such as e.g. pyproject.toml do not have a distinction between “development” and “runtime” dependencies. However a growing ecosystem of nix powered devshells (with additional tooling) seems to indicate that such a distintion is needed to improve dependency clarity. Currently, those are often just carelessly “mixed” together.
Patches to source code that represents an input should be treated as inputs, too. Simple.
follows
Overlays and inputs.<name>.follows are functional equivalents. We should settle on inputs.<name>.follows notation, since those:
Enforcing a one-level-deep hierarchy on the output contracts has been poorly understood and the original reasons can be traced back to “more efficient indexing” (aprox. Elco quote burried in some PR discussion).
It seems like people would prefer to abandon this contract.
Especially for libraries, it might be desirable to specify version boundaries for inputs on which compatibility is guaranteed.
Increasing nesting of the follows syntax might lead to situations where optimzing for closure size (= e.g. pining all inputs to a specific nixpkgs version) might lead to hard-to-understand compatibility problems.
By allowing (very conscientious) upstream libraries to declare explicitly their compatibility boundaries (e.g. git’s own <hash>..<hash> notation) would allow firendlier errors and tooling around this class of problems.
</details>Where does flake.toml come from? I don’t mind separation of metadata, but it’s metadata for a default.nix file that likely consists of more intense Nix code than what the metadata declarations would be. Also, at the risk of undermining the previous sentence, changing from Nix to TOML for this file also means that metaprogramming of that data, on the few occasions it does happen, will become a lot more opaque. Flakes will need friendly, official documentation to be approachable, and if that’s the case, the introduction stating
{
flake.supportedSystems = [
"x86_64-linux"
"x86_64-darwin"
];
inputs = {
...
instead of
[flake]
supportedSystems = [
"x86_64-linux",
"x86_64-darwin",
]
[inputs]
...
is not going to be a big deal. This amount of complexity, in Nix or TOML, all reads close enough to less-strict JSON that I don’t think people will be thrown off. Nixpkgs’s lack of comprehensive documentation discourages people from picking it up or sticking with it the most, in my opinion, and flakes are a worse version of that currently. All the documentation for flakes I regularly reference is unofficial, save for nix3-flake(1), and referencing the relevant parts of Nix’s source when I have questions is much less pleasant than referencing the relevant parts of Nixpkgs’s source.
Despite how flakes are unstable & the unofficial flakes roadmap is unofficial, I’d really love to see polished, comprehensive, as-official-as-possible documentation for flakes (+ the unofficial flakes roadmap) as they are right now. People who currently use flakes can have a single reference to use & share when others ask. People who are looking into flakes can have a reference they know about & feel confident trusting that won’t unexpectedly leave them to fend for themselves in a confusing section. People who are holding off on flakes can have an accurate way to gauge how flakes are shaping up and quote from an uncontentious source when discussing their thoughts on flakes.
If we have that sort of documentation, and people feel like those bits of metadata being written in Nix instead of something else is a hang-up, then go for trying out TOML. The current flake situation being disorienting for experienced Nix users though makes me hesitate for now.
As a newcomer to Nix (started in May this year), who comes from the ops/packaging/OS side with loads of experience in Debian but no prior interest in functional programming, I love Flakes and the new nix-command. The ergonomics and flags of the various subcommands I’ve encountered (build, develop, eval, hash, store, show-derivation, path-info, why-depends) all seem to basically make sense, locking is sane and easy to reason about, and when I’ve gone to hack on nixpkgs itself, I’ve found it straightforward to understand the difference between nix build .#foo (my local version) vs nix build nixpkgs#foo (the current master).
Honestly, my main complaint is still just that basically all of the documentation pages, tutorials, pills, etc still refer to nix-build or nix-shell, none of which seem to work without a default.nix that contains (what feels to me) like a lot of mystery-meat stuff centered around import <nixpkgs> {}.
So anyway, I understand that there are some legitimate technical/philosophical/governance issues at play here, but I want to register my appreciation for what has been done so far to get Flakes where it is.
I think flakes are a great, however the fact that you cannot compute the inputs seem to be overly restrictive. I have created an
issue, where I have included all the other issues on that point. If you know about any other issues that I have missed or if I’m missing something fundamental about flakes please let me know. Any feedback would be great 
.
This reminds me of the allowUnfree issue: it very likely must be a flake input too. The current way of importing nixpkgs with { config.allowUnfree = true; } means that a flake user has no chance to explicitly accept the license
There is more and more tutorials popping up, advertising the use of flakes. I am still hesitating because it is experimental, but would like to advertise it myself for projects of mine.
This is the best thread I could find in order to get a roadmap for the future of flakes.
Is there any progress for an RFC or similar?
There’s this announcement: Nix release schedule and roadmap
nix 3.0 would mark the stabilization of flakes (as that roadmap states), so it’s the closest thing I’m aware of. But there may be a more up-to-date roadmap somewhere
There was a summer of nix talk given just a few hours ago where @edolstra discussed a little bit about the roadmap for flakes. Trying to formalize a roadmap process and a desire to stabalize flakes with an RFC. I got the impression that the stabalization discussion/RFC would begin fairly soon. But it sounds like he needs to work with the community to make anything concrete.
https://youtu.be/h8hWX_aGGDc?t=2900 links the portion of the talk where the roadmap is discussed.
For me, the main issue with flakes is copying the entire Git repository to the Nix store. As far as I understand, Nix does this for the evaluation cache, but in my opinion, the evaluation cache is not the main feature of flakes and could have been implemented as another experimental feature.
@misuzu That is being fixed soon™ with Source tree abstraction by edolstra · Pull Request #6530 · NixOS/nix · GitHub
To be clear, “soon” means “when it’s done”.
But also connotes the hope and eagerness of many users like me, who, in addition to recognizing that rushing such a complex PR through would cause more harm than good, have been looking forward to the completion of that work for a very long time (years now). 
Thanks in advance to @edolstra for all the time he’s put into that abstraction and @roberth for his work in reviewing that PR and trying to move it forward without breaking things. I’m going to be so happy when that feature lands!