Hello Nixers,
I deeply wonder how do you guys go about making commits for a project on, for instance, github that has no *.nix files to build it, while not forcing a maintainer to use Nix?
Do you make your own repo with *.nix files to build a project?
Any of your tips on that matter would be extremely vital to me, as I don’t want to force a project maintainer to add another configuration files to their already complicated project…
Thanks in advance !!
You could try and .gitignore them or create a flake in its own repo and use nix develop to access a specific dev shell
Personally, I just write out either a flake.nix or shell.nix and keep them in the same repo. Since they’re untracked files, they don’t mess with my Git workflow (unless I accidentally do git add . :D)
If it’s not a big project and I’m in touch with the devs outside of GitHub, I also try to onboard them to using Nix; not forcibly, of course.
In case the project is already packaged in nixpkgs you can get a development environment for it using
nix-shell ~/a/local/nixpkgs -A the-package
(This might work better or worse depending on the language ecosystem of the package and depending on how much patching the package requires in nixpkgs)
See also: nix-shell - Nix Reference Manual
By default flake.nix must be tracked by git, IIRC. If you want to put it outside of the repo, you need some additional config to do.
However, shell.nix indeed works regardless of git state.
Woow, thanks a ton for so many useful replies, I’ve just come back to using NixOS after a one year break and I am not regretting it. This forum is freaking amazing and extremely motivating.
@GetPsyched’s answer is good but would be great if I could keep the nix config not only locally but also remotely while also being able to use flakes as @ShrykeWindgrace wrote 
@knedlsepp Interesting and probably the simplest, but it requires me to have the whole nixpkgs repo locally on my system, am I right?
@hugo.berendi’s 2nd solution seems crazy good for me but I’ll try to elaborate on what I’ll try to do, tell me if that makes any sense:
master-nix branch where I’d add all *.nix configs and keep rebasing it with original master branch.issue-nix branch from master-nix solving some issue (still using nix)issue branch from issue-nix and delete all *.nix files.This way I would have my configs on the same repo, both locally and remotely, while not messing up the original repo.
What do you guys think about this approach? It popped into my head when I woke up today 
Usually, yes. But there’s a flag in Git: git add --intent-to-add flake.nix. This adds the file to the set of tracked files but doesn’t stage it for a commit, so it more or less stays out of my way. Perfect middle-ground, IMO. Thanks to @mightyiam for telling me about it!
I agree; there are some great people on here who help others out of their own will and free time, I don’t think it’s appreciated enough.
Yeah it’s tough; the problem with keeping a commit for it is that it will show up on your PRs. For me, keeping the file tracked-but-not-staged in Git has worked fine for the most part. Though I really like @hugo.berendi’s approach and might use it myself.
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 
@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
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.
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.
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.
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.
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…)
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
It’s one of the best tools to go alongside Nix.
Makes it even more magical.
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…)