Yes - I do. HEAVILY.

We use nix-direnv internally (though we might switch to flake_env at some point if I can get the flake_env implementation up to snuff with nix-direnv features).

We start with devShells for the basic stuff. For instance, we do a LOT of python here (against my wishes) and so we'll start with a devShell that just installs latest python. We then start poking around nixpkgs for stuff we need as we need it and use that. I tend to prefer this solution over dream2nix or poetry2nix, as I have found at least poetry2nix to be rather fragile (haven't tried dream2nix).

We have a fair amount of interproject dependence and we simply bump as necessary. Myself and a coworker manage a lot of the dependencies and so we are aware of breaking changes and the like without needing to spend a ton of time on it.

Regarding CI: We have used Github Actions, GitLab CI, and I have started using sr.ht's build tooling. Both github and gitlab have been perfectly fine. Sr.ht's is a bit more basic, but for what I am doing there that's fine and dandy.

Regarding follows, I think tomberek is saying that setting something like inputs.foo.nixpkgs.follows = "nixpkgs" to force it to follow your local nixpkgs input can be troublesome and I kind of agree. Right now I have a small problem in flake_env whereby I had accidentally bumped an underlying library revision in a way that's not compatible with stable becuase it explicitly follows unstable. When I tried to build it as part of my system flake, I ran into issues because I had it set to follow my local nixpkgs. This isn't a huge deal because it provides only a simple binary and can be built in isolation, but for node.js or python code using revisions from nixpkgs, you could be up a creek without an effective paddle if you rely on this.

do flake.locks have a specification? I looked through both the rfc repo and the nix repo and couldn't find anything except for soure code. I would assume that there should be some formal-ish document describing the format esp. since there is version field in every flake.lock.

context of this question is that yesterday I read through the robotonix docs and stumbled upon the over-the-air updater which is just a number that increases every version, so usually `date "+%s". this reminded me of the problem I had with the soa record serial field when I built nixos-dns which uses the exact same format to detect updates/changes.

locking at a random flake.lock I noticed that every entry, except for root, has a locked.lastModified field that is just a unix epoch which is the data one could use for soa serials or ota versions and probably other things. And seeing how flake.lock files are just json you could even parse them with builtins.fromJSON. But root which seems like it is the flake it self doesn't have this field.

In reply to @janik0:matrix.org

do flake.locks have a specification? I looked through both the rfc repo and the nix repo and couldn't find anything except for soure code. I would assume that there should be some formal-ish document describing the format esp. since there is version field in every flake.lock.

---

context of this question is that yesterday I read through the robotonix docs and stumbled upon the over-the-air updater which is just a number that increases every version, so usually `date "+%s". this reminded me of the problem I had with the soa record serial field when I built nixos-dns which uses the exact same format to detect updates/changes.

locking at a random flake.lock I noticed that every entry, except for root, has a locked.lastModified field that is just a unix epoch which is the data one could use for soa serials or ota versions and probably other things. And seeing how flake.lock files are just json you could even parse them with builtins.fromJSON. But root which seems like it is the flake it self doesn't have this field.

In reply to @lxsameer:matrix.org
hey folkss, when running nix store gc, how does nix know what to delete? does it know what flake.lock files do I have?