I want to share a trick that I just discovered. You might want to try out flox on a repository but you don’t want yet to commit the flake files and share them with your teammates.
Tell git to track flake.nix but without adding it:
git add --intent-to-add flake.nix
Tell git to assume that flake.nix doesn’t have any changes:
git update-index --assume-unchanged flake.nix
This way you end up with a clean git status, but flake.nix still being tracked by git and therefore accessible to Nix. The only restriction is that you can’t do git operations which would modify/remove the flake.nix
There are a few variations possible here. Each of these is “I, as the user, want to interact with a project …”.
“… without modifying the existing repository”
“… using an alternate directory”
“… untracked by any git at all”
“… tracked by git in current repository”
While these are all possible, I’d like to trim them down and simplify to the bare minimum to make it easier to document and provide best-practice recommendations. My hesitance to recommend “intent-to-add” is that it uses a portion of git that is unfamiliar to most people and it is likely to put repos into unexpected states.
I you have ways to do 1. and 2. I’m all ears! My intent is to not have to commit the flake files. I wouldn’t mind if they were just ignored with .gitignore for example.
If you don’t want nix code in your project repository I’d recomend
You create a new project separate from your project.
.
\
my-project
\
my-project-flox
There might be other ways using git worktree and friends to keep this flake directory in your project directory if necessary - but that’s beside the point here
in my-project-flox you perform your flox init cycle creating the various *.nix files in there.
You now link your original project to that flox poject:
{
description = "Floxpkgs/Project Template";
nixConfig.bash-prompt = "[flox] \\[\\033[38;5;172m\\]λ \\[\\033[0m\\]";
inputs.flox-floxpkgs.url = "github:flox/floxpkgs";
inputs.flox-bash.url = "git+ssh://git@github.com/flox/flox-bash";
inputs.nixpkgs.url = "dummy";
inputs.nixpkgs.follows = "flox-floxpkgs/nixpkgs/nixpkgs";
# Declaration of external resources
# =================================
inputs.my-project = {
url = "github:owner/repo"; # (or an absolute path to your local source if you dont intend to share the flox project)
flake = false;
};
# =================================
outputs = args @ {flox-floxpkgs, ...}: flox-floxpkgs.project args (_: {});
}
with this you can now refer to inputs.my-project in your pkgs/*/default.nix by replacing source references to self with inputs.my-project
{
rustPlatform,
fetchFromGitHub,
inputs, # < include inputs
}:
rustPlatform.buildRustPackage rec {
pname = "my-project";
version = "0.0.0";
src = inputs.my-project; # < used to be self;
cargoLock = {
lockFile = inputs.my-project + "/Cargo.lock"; # < used to be self + "/Cargo.lock"
};
}
This will create a flake.lock file which needs to be updated when the upstream source changes using flox flake update
do I need to create a git repo in the project-flox directory? Does it need a remote URL?
which nix files need to remain in the project directory? Am I suppose to add them to .gitignore then?
which nix files should be in the project directory? Must they be committed locally?
But actually I am maybe overthinking this. I can create a project-flox directory with all the nix files, open a flox develop session there and navigate to the project directory to open an IDE or use cargo. That might be the simplest thing to do isn’t it?
The idea is to have no flox files in your original project.
As you say
This is what i was implying. Do all flox work in one repository, then in a flox develop environment change to your project.
The my-project-flox directory would need to be a git repository but does not necessarily need to be pushed to a remote server.
You can also just add your original project as e.g. git submodule of the project-flox repo .
Mind, as @tomberek mentioned there are several ways, each with their own annoyances.
I’ve been using this approach successfully before, when the original project is not ready to include the nix setup. Also, the whole of nixpkgs the core nix package set is based on this approach.