4 ms·
The documentation is not much aimed on a developer workflow. The `shell.nix` files make it easy to place the environment setup in your repository. The file con
by oever 7y ago
The documentation is not much aimed on a developer workflow.
The `shell.nix` files make it easy to place the environment setup in your repository. The file contains the list of packages that you need and you can make these packages available in just one shell by calling `nix-shell`.
Here's an example of a `shell.nix` file:
with import <nixpkgs> {};
stdenv.mkDerivation {
name = "cv-env";
buildInputs = [
libxslt gnumake openjdk entr
];
}
- the_duke 7y agoI tried to do this, but I ran into way too many problems. Each approach I tried failed because of some limitation that made the whole thing awkward or pointless. (like symlinking immutable config files into $HOME) This admittedly might have been exacerbated by my shallow understanding.
- danieldk 7y agoEach approach I tried failed because of some limitation that made the whole thing awkward or pointless. Could you explain the limitations that you've run into? I have been using shell.nix + direnv + some caching for 1.5 years now and I have been very happy with it. The only thing I disliked is that shell.nix is underspecified in the sense that it by default relies on your configured nixpkgs channel. So, I am now using niv to pin down nixpkgs and other package sets (mostly my own) to specific revisions. Once Nix flakes become mainline, this can be done easily without third-party tools.
- lidHanteyk 7y agoI do this. When I run into problems with a shell.nix, I fix the underlying project, or abandon it. Nix is ruthless but being ruthless is required in the face of the task of taming decades of terrible software.