Add rust-toolchain and nix flake

[doriath]

rust-toolchain will allow us to ensure that everyone developing on the repository is using the same version of rust.

Nix flake will provide out-of-the-box development environment for nix users with the right rust version.

[kubouch]

I'm fine with the toolchain file (to match the version that Nushell uses) but so far, we've refrained from including package manager--specific files (like flakes) from our repos. We created this repository https://github.com/nushell/integrations to gather these kinds of files. Could you put it there instead?

[doriath]

I fully understand that nix/flake is a little invasive to a project. Let me go over some options, and we can then decide. I am sorry in advance if you were already aware of all the options and you decided to go with integrations repo option.

I believe the main things we should evaluate is:

• experience for nix user that wants to contribute
• effect on structure of the repository
• maintainability for repository owner

Here are some options I see:

1. flake in root dir + direnv - this is the best setup for a nix user. I just enter a directory with a repository, and I automatically get all required dependencies and tools available to start contributing. This requires 2 nix specific files (flake.nix and flake.lock) and .envrc for direnv (the last one could be used for other things, I believe nufmt automatically activates toolkit.nu on entry). Because the files are in the repo, you will be getting PRs to fix / improve it, which will be some toil.

2. flake in root dir, no direnv - similar to above, but to start developing one would have to run nix develop -c nu. Slightly worse ergonomy, but standard invocation, nothing to learn or remember for nix user. One less file (.envrc) in root directory

3. flake in subdirectory, no direnv - this is an option that is discussed on main nushell repo (which someone said they would be ok with merging). Nix user would have to run nix develop ./scripts -c nu to start developing. Slightly harder and less standard, as one has to remember the directory where flake is located (and it might not be immediately clear to the contributor that it exists somewhere). It eliminates all files from root directory, we just need subdirectory where to put the files.

4. flake in subdirectory + direnv - I would need to explore those options a little more, not sure what would be possible.

5. flake per repo in separate repo - every repository is different and will require different set of tools. We could create a separate flake in integrations repo for every repo. This will be harder for nix user, as they will need to remember the exact github path every time they want to contribute to a repo. But it improves the maintainability for new-nu-parser repo, as it is completely out of the picture here.

6. one flake in separate repo - similar issues to (5) to start using, and also it means we need to install all dependencies for all repositories. For example tree-sitter-nu requires tree-sitter tool, while the parser repo does not need it.

7. Do not provide support for nix users. Nix user will have to come up with the right nix shell invocations to get all dependencies required to contribute to the repository. This eliminates any maintainance / toil on repository owner. Not many repositories support nix, so it is a totally reasonable approach.

I am biased because I am a nix user, and getting any of the 1/2/3 options would be the best for me. If the cons outweigh the pros for maintainability of this repository, I totally understand and will follow in that direction. Please let me know your preference and I will update this PR.

[doriath]

I was doing a little more research to see what other repos do and what are the options.

envrc/direnv:

• I now think that option (1) is not actually good, as it disallows users from using their own envrc if they use another process than nix to manage development. Here is a discussion from helix editor repo that got me to this conclusion: Why is there an `.envrc` in the repository? helix-editor/helix#12313

• I like the solution that jj-vcs/jj repository took - add .envrc to .gitignore and instead introduce .envrc.recommended. That way if user wants to use nix, they can run one command (echo "source_env .envrc.recommended" >> .envrc) and get automatic nix environment.

flake files:

• I learned it is possible to use custom paths and even remote flakes (e.g. use flake github:nushell/integrations), so it seems options (4-6) should be feasible

.gitignore

• I learned that there is a way to exclude files in repository without causing changes to the repo (by changing .git/info/exclude), so I can set up my environment without affecting this repository

Final thoughts: Based on the above, I found a way to get the best experience for me (similar to option (1)) with minimal work on my side and with no changes to this repository. If we decide to go with (7 - no support in the repo), we could also consider few minor changes:

7.1 - add .envrc and .direnv to .gitignore - that way one can setup .envrc with no changes to local .gitignore
7.2 - add flake.nix, flake.lock and result/ to .gitignore
7.3 - add a section in some CONTRIBUTING doc / section, about how nix can be configured in the repository

Please let me know if you would like to go with any of the options above (or any other direction), and I will be happy to update the PR to match it. If you believe no changes should be made, please just close the PR.

[kubouch]

We had a conversation about our flake.nix policy with the core team and agreed that we won't block people trying to add them. It has been coming up repeatedly and if people are willing to maintain them, then why not, if it makes life easier for Nix users. So we're OK adding flake.nix and friends to the repo (and other Nushell repos).

In any case, with these files related to specific tools, it would be good to add a comment there explaining roughly what the files are, e.g., for someone who's never heard about Nix, flakes, direnv, etc.

[doriath]

Updated the PR

• split rust-toolchain and nix into two commits
• rabased on the HEAD commit
• removed .envrc and added .gitignore (as I mentioned on the most recent comment)
• added additional comments explaining what nix / direnv is and how it can be used

[kubouch]

OK, cool, we can merge it, but there is a conflict.

[doriath]

Rebased

[kubouch]

Thanks!