Allow .nix/flake.nix as an alternative to flake.nix

[edolstra]

Some people don't want to pollute the root directory of their repo with stuff like flake.nix. So similar to .github, we could put files like flake.nix in a hidden .nix directory.

To avoid ambiguity it should be an error if both flake.nix and .nix/flake.nix exist.

CC @leenaars.

[andir]

Would this change anything with the requirement of the flake.nix to be tracked by version control? This is one of the issues I frequently encounter when working with projects that do not support Nix but I use Nix for local development.

[leenaars]

An idea I had this week was to seek a generic and more scalable solution. There is an IETF standards track RFC that defines a default folder for discovery of this kind of "meta-data": https://tools.ietf.org/html/rfc5785 ; it basically says: toss such files in a folder canonically named .well-known. This declutters the main folder and acts as a sandbox, to reduce the risk of collisions. The mechanism is used also by e.g. Let's Encrypt, Matrix, and many standards like webfinger, jmap, Do Not Track policies, etc)

The cool thing is of course that wherever you have a self-hosted code repo (sftp://project.example.org), tossing in the repo with the nix flake in the .well-known location would immediately make the flake discoverable on the web for tools that understand .well-known.

.Well-known comes with a registry ("the well-known URI registry"), and it should be straightforward to register flake.nix in it: https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml

(it would work without claiming flake.nix through the registration too, but it would be following good practices to do so)

From my perspective, there is no cost and only benefit to the wider software ecosystem if we all woud start using a consolidated well-known folder for the different packaging systems - rather than just having a folder with one file in it named after the packaging mechanism.

[leenaars]

Would this change anything with the requirement of the flake.nix to be tracked by version control? This is one of the issues I frequently encounter when working with projects that do not support Nix but I use Nix for local development.

To comment to that concern: dotFiles and dotFolders by default are tracked by version control systems like git like anything else you put into the folder. Git for instance even uses them itself for core functionality, e.g. for the .gitignore file which is used to flag files that are present in the folder but should be kept out of git.

You can use the .gitignore file to change the default behaviour, and not track your local flake.nix, .nix/flake.nix or .well-known/flake.nix (wherever this ends up).

[zhaofengli]

This may be problematic when you try to implement something like #4612 in the future because you are essentially saying that a flake contains the contents of whatever directory flake.nix lives in, unless that directory is named .nix in which case the parent directory will contain the contents. We now have a special case, and more will be added if we follow through with .well-known and other schemes. We will also run into other issues where a hypothetical project may have .nix as a git submodule, in which case the current behavior they are relying on will be broken and #4423 will also gnaw its teeth.

I'm not saying this isn't a good idea (it may improve UX), but please consider it very carefully. I treat flake.nix as something like package.json (Node) and Pipfile (Pipenv), and the location of those manifests unambiguously mark where the project is. Both of those tools automatically discover the project by traversing the parent directories, which would actually be a huge UX improvement for Nix.

[poelzi]

I suggest 3 names:

• flake.nix
• nix/flake.nix
• .nix/flake.nix

This way it is very easy to choose which kind of "pollution" you like. The nix folder has the advantage to be visible but only have one folder ever top level. Last one is for the project with problematic people