You could do this, but this falls apart when your PR is reviewed and someone requests changes. What do you do now? Rebase on master-nix to get the Nix files back, then drop the commit before force pushing to your issue branch? And do this every time you work on the branch? Oof, that’s a lot of work.
Oh yea, haven’t thought about that, you’re totally right 
1 Like
@knedlsepp Interesting and probably the simplest, but it requires me to have the whole nixpkgs repo locally on my system, am I right?
You don’t need to clone the repo, but it’s convenient because it’s likely you will want to tweak the derivation or check out a specific nixpkgs commit.
If you don’t want to clone the repo you can always use your system’s channel:
nix-shell '<nixpkgs>' -A the-package
1 Like
Heey, but how about switching to master-nix, running nix develop and switching back to the branch without any *.nix files? Would it work?
I would suppose so, yes.
1 Like
I do something like you describe with having a main-nix branch. Changes I make are commits on a feature-nix branch off of main-nix. For a PR, I then have a separate feature branch to which I cherry pick the commits implementing the change I want to upstream. Changes to the PR are developed and tested in feature-nix, then similarly cherry picked back to feature.
2 Likes
I do something similar to this and it works really great:
The only difference is that I’ve also set up direnv in the parent directory so that I auto-activate the dev environment when I navigate to any sub-directory.
Also, I don’t have the flake.git file tracked at all since the parent dir is not a git repo, but I haven’t encountered the copying problem in the other post since the dev shell is cached by direnv.
4 Likes
We do something similar at work.
We have dev project and inside that we keep a var/ directory that is in git ignore.
Inside of it we have multiple projects that all use the the parents devShell, more specifically a devenv that provides PHP, Nginx, etc.
2 Likes
Another option is to have a nix setup one level higher, a project checkout inside, and just enter it once the setup is done. (The setup might or might not be also using FHSenv, doesn’t matter in this case…)
3 Likes
So It does make sense what I wrote above, Nice !!
Hmm, never in my life have I used direnv, will take a look at that, really interesting
1 Like
It’s one of the best tools to go alongside Nix.
Makes it even more magical.
3 Likes
This is exactly what I do!
It has the added benefit of enabling multiple worktrees to share the env (e.g. /project/main/, /project/branch-1…)
1 Like
You could pair @7c6f434c’s suggestion with Git worktrees which allow you to branch off in a different directory, which in this case can be one level deeper!
So, in theory, you could have the main branch having your dev setup, committed or not doesn’t really matter, enter nix develop (or use direnv), and then spin up a worktree in a directory one level deeper and have everything setup neatly.
Full disclosure, I haven’t used Git worktrees much myself, so I’m not sure if this works; but from my limited understanding of them, I think this can be a solid approach. I’ll try it out myself sometime soon.
2 Likes
Git worktrees are in principle a viable approach, maybe even the only morally correct one, but you’ll likely have to duct-tape together lots of helper tools to manage them fluently because it’s still just strings in files, and Git UX is meh.
2 Likes
Untested thought: would git subtrees work here? You could just create a new repo and then vendor the repo you want to contribute to in a subdirectory. The parent directory could contain the flake.nix. And then you have a nice UX to push back commits to that subdirectory.
I usually create shell.nix + .envrc files in the same repo and ignore them locally only in that project
echo ".envrc\nshell.nix" >> .git/info/exclude
The only reason I never used flake.nix in these situations was because it had to be tracked and I didn’t know about the git add --intent-to-add shared by @GetPsyched, so I will probably give this a try and see.
Worktrees should also work, I use them sometimes in large repos/projects but I find them a bit of an overkill for smaller repos/projects. This is clearly subjective, but it should work fine.
3 Likes
Reviving this topic after a bit of time, the way I am doing it is the following, tremendously trivial:
- I have a
master-nixwhere I store all the*.nixfiles. - I run
nix develop --profile nix-envwhile onmaster-nixbranch. - And have a
nix-envprofile where I can justnix develop nix-envinto it and run tmux so that I have the same dev environment across alltmuxwindows and not having it tracked so that I can work on any branch, make PRs from it, and so on.
How do you Nixers rate my final approach? For me it’s really cool and simple
just
nix develop nix-envinto it
which version of nix are you using? with nix 2.18.7 I get error: cannot find flake 'flake:nix-env' in the flake registries with that command.
It should be: nix develop ./nix-env not nix develop nix-env. My mistake, sorry !