Alternative to .config/nixpkgs/config.nix:packageOverrides

This sort of problem is a big part of why we created flox in the first place. There exist many ways to use Nix, and the fast pace of change in the Nix world means that conventions change quickly and things can stop working, particularly if you inadvertently revert to a previous Nix version.

That said, there are three things I’ll note from what you’ve said above:

  1. nix-env is deprecated. It didn’t record the original attrPath used to install a package so it was fundamentally broken from the start, and has been replaced by the nix profile command(s).
  2. nix profile is experimental and unstable. You may be running into problems between the use of different versions of Nix which employ different manifest “version” numbers, and once a profile has been accessed (even once) by a newer version of Nix it can no longer be read/used by an older version.
  3. flox environments fully replace Nix profiles, supporting full change management and sharing features not possible with Nix profiles. These are discussed in detail in the flox tutorials, so if you haven’t already I’d suggest reading through the Using Package tutorial and don’t stop until you’ve finished the “Sharing Environments” section.

In summary, I believe you should find that flox install nixfmt nix-direnv jq tig followed by flox activate should get you the environment you’re looking for, after which you can flox push and flox pull it to other machines, and/or share with a team by inviting them to flox pull -e hellwolf/default.

One final note: we’re working on a flox installer for WSL which should help avoid such Nix version mismatches in future, but in the meantime you may find that running alias nix="flox nix" may provide some relief in the meantime.

Hope this helps!

1 Like