5 ms·

IMO the biggest blocker is documentation. The best way to figure out how to do something is typically to search around in the nixpkgs/NixOS options for what yo

IMO the biggest blocker is documentation. The best way to figure out how to do something is typically to search around in the nixpkgs/NixOS options for what you're trying to do, then go read the code. There's very little in the way of "here's a common task that new users want to do and here's the blessed way to do it." Even something that should be Nix's MAJOR selling point, like "create a single repo that configures a bunch of machines, including some NixOS and some other OS" doesn't have a recommended way to do it. Another challenge with the docs is the fact that Nix is * An OS * A package manager * A way to manage dev environments A lot of times I find someone who solves my problem but they solve it in the context of building a dev environment and I want to do it in the context of setting up an OS package. It means that even with all the good tutorials and blog posts out there, you might still have a bunch of work to do to get things to work how you want. This translates into tons & tons of opportunities for users to give up. Also, for some reason, so many examples are done in the imperative manner, and it's not always super clear how to translate them to a declarative setup. Again, just defeating the strengths of Nix and clouding the benefits. If a new user sees a bunch of examples that involve starting nix-shell and installing some dependencies it's both hard to understand the benefits and hard to translate that to a declarative setup.

gugagore 5y ago
It sounds like nix provides an escape hatch [1] out of the declarative framework into something imperative, e.g. running `apt install $package`. And that seems like it would really ease adoption, since I would assume that it would allow a gradual adoption of the declarative mindset. [1] https://wiki.c2.com/?EscapeHatch https://wiki.c2.com/?EscapeHatch
- mason55 5y ago
  IMO the escape hatch doesn't get you any real benefits. It's not like you can install packages from apt/yum/aur so you don't get access to any new software (plus nixpkgs is bigger than all those). All it does is result in confusing tutorials that hide the benefits of declarative management and make it difficult for new users who just want to get things working.
  - chriswarbo 5y ago
    > It's not like you can install packages from apt/yum/aur Yes you can. Here's a Nix derivation which makes a Debian chroot and runs 'apt-get update; apt-get install -y chromium' https://github.com/Warbo/warbo-utilities/blob/7087c3b46a97f3fe0280cb0da74b265558856b14/scripts/in-chromium-env.nix https://github.com/Warbo/warbo-utilities/blob/7087c3b46a97f3... Here a Nix derivation for a helper script that runs the above chromium: https://github.com/Warbo/warbo-utilities/blob/7087c3b46a97f3fe0280cb0da74b265558856b14/scripts/chromium-launcher.nix https://github.com/Warbo/warbo-utilities/blob/7087c3b46a97f3... On a similar note, here's a Nix derivation for Mozilla's Firefox binary (in an FHS env), along with a warning if it's not the latest version: http://chriswarbo.net/git/warbo-packages/git/branches/master/packages/firefoxBinary.nix.raw.html http://chriswarbo.net/git/warbo-packages/git/branches/master... I wrote these once cache.nixos.org stopped providing "non-core" i686 binaries a few years ago, and I can't be bothered to build those large applications from source.
    - mason55 5y ago
      Oh yeah, great point! I was thinking of installing packages from apt/yum/aur directly with something like nix-env, but you're right, there's no reason you can't just use apt-get directly.
- kevincox 5y ago
  It does for some things. For example you can run `nix-env -iA firefox` to install firefox (for your user) without changing the config. (Or even better `nix run nixos.firefox -c firefox` to run it without installing) However some things like adding/editing files in /etc is a lot harder as those paths are basically recreated on boot.
- chriswarbo 5y ago
  A few things which might count as "escape hatches": The `runCommand` function lets us define a "package" by just executing bash code. This avoids all the "phase" machinery that most nixpkgs definitions use (those phases are great for fine-grained overriding; but we don't usually needed to override our own definitions). It takes 3 arguments: the output name, a set of env vars (including `buildInputs` which will populate $PATH) and a string of bash code (which can be multi-line using ''two quotes''): $ nix-build -E '(with import <nixpkgs> {}; runCommand "hello.txt" { buildInputs = [ foo bar baz ]; } "echo hello > $out")' these derivations will be built: /nix/store/z6ffwc1jb70zwz2ly42gaalxnvm7q0gk-hello.txt.drv building '/nix/store/z6ffwc1jb70zwz2ly42gaalxnvm7q0gk-hello.txt.drv'... /nix/store/l6sd75hj4854pdzv4044ma42axc2v5v4-hello.txt The sandbox can be selectively disabled (via whitelists), or turned off altogether, which allows builders to access arbitrary filesystem locations and the network. For example, if we have a Python pip project, and we want to take a baby step towards Nix, we could do this (assuming the sandbox is disabled): with import <nixpkgs> {}; runCommand "my-app" { buildInputs = [ (python3.withPackages (p: [ p.pip ])) ]; } '' echo "Making mutable copy of app" 1>&2 cp -r ${./.} "$out" chmod +x -R "$out" echo "Putting dependencies in place" 1>&2 pip3 install -r ${./requirements.txt} --target "$out"/ '' There are all sorts of other tricks. For example, Nix will make immutable copies of files if we reference them directly like ./foo (these copies are stored in /nix/store). If we don't want that, we can reference a symlink instead, since the resulting "immutable snapshot" is just a link to our mutable, non-/nix/store path. We can avoid having to hard-code hashes for "fixed output derivations" (like downloaded URLs) by overriding their `outputHash`, `outputHashAlgo`, `outputHashMode` and `sha256` to `null`. I wrote up a bunch of these sorts of hacks at http://chriswarbo.net/projects/nixos/useful_hacks.html http://chriswarbo.net/projects/nixos/useful_hacks.html (although its a few years old, so might not be up to date) Of course, these things aren't advisable; but they're very useful to get up and running quickly, and things can be made "more Nixy" later.
- pxc 5y ago
  nix-env isn't meaningfully an escape hatch, since you can still only use it with stuff that's packaged in Nix's peculiar way. Here's an overview of the escape hatches that are currently around in NixOS for package management, meaning you can use them to avoid packaging something natively for Nix, or to run pre-built software for other distros or targeting multiple distros: • flatpak — use flatpak to install stuff just like you would on any other distro: https://nixos.org/manual/nixos/stable/index.html#module-services-flatpak https://nixos.org/manual/nixos/stable/index.html#module-serv... • FHS user environments — create a usermode chroot that puts Nix packages where naive `./configure; make; make install` programs will expect to see their dependencies • steam-run — run whatever in the pre-built FHSUserEnv that Nixpkgs uses for Steam: https://nixos.org/manual/nixpkgs/stable/#sec-steam-run https://nixos.org/manual/nixpkgs/stable/#sec-steam-run • AppImage — launch an AppImage using `appimage-run` or create a quick and dirty Nix package that wrapps an existing AppImage: https://nixos.org/manual/nixpkgs/stable/#sec-pkgs-appimageTools https://nixos.org/manual/nixpkgs/stable/#sec-pkgs-appimageTo... • Docker — you can run stuff with Docker if ya want: https://search.nixos.org/options?channel=unstable&show=virtualisation.docker.enable&from=0&size=50&sort=relevance&query=docker.enable https://search.nixos.org/options?channel=unstable&show=virtu... NixOS also includes little escape hatches on the configuration side for every service. Basically every module also has an ‘extraConfig’ type of option, which lets you append to the config file that NixOS generates for the service in its original/raw format. Otherwise, you're generally looking at setting up a chroot environment. I can think of some ways that NixOS could be a little more generous with escape hatches, but I don't think there's much developer interest in the community.
  - mason55 5y ago
    > Basically every module also has an ‘extraConfig’ type of option This is actually changing so that the additional config can be merged/validated even if it can't be typed https://github.com/NixOS/rfcs/blob/master/rfcs/0042-config-option.md https://github.com/NixOS/rfcs/blob/master/rfcs/0042-config-o...
    - pxc 5y ago
      This is pretty exciting! In this case, users will retain an 'escape hatch' in the sense that they'll be free to descend from whatever higher-level configuration options a module author wants to offer (which could set multiple settings, or generate settings based on other settings) and use all the configuration primitives offered by the underlying software being configured. We just won't have to manage it as a big, dumb string anymore. :D I suppose this could still be annoying for someone who really just wants to copy/paste, though.
Nullabillity 5y ago
> Even something that should be Nix's MAJOR selling point, like "create a single repo that configures a bunch of machines, including some NixOS and some other OS" doesn't have a recommended way to do it. NixOps[0]? But yeah, it isn't featured as prominently anymore as it used to be... [0]: https://github.com/NixOS/nixops https://github.com/NixOS/nixops
- mason55 5y ago
  NixOps is fine for pushing changes to machines (well, actually I think it has a lot of problems, and somehow the NixOps docs are even worse than the regular Nix docs as far as getting started and bootstrapping and doing basic tasks, but that's not the point). But it's all about the mechanics of pushing changes to your hosts. It certainly doesn't give you any kind of opinion on how to, say, structure a repo that has your hardware configs, Home Manager on a non-NixOS machine, Home Manager on a NixOS machine, some systemd services, etc. And there's no reason to need NixOps to maintain a repo of three or four physical machines that you have around your house.
  - squiggleblaz 5y ago
    > And there's no reason to need NixOps to maintain a repo of three or four physical machines that you have around your house. You don't. You can use `nixos-rebuild test --target-host=red --flake .#red`. If you want to build locally, add --build-host=localhost. NixOps gives you the advantage of not having to repeat yourself, but you could easily whip up a shell script for `rebuild-switch red`.

gugagore 5y ago

It sounds like nix provides an escape hatch [1] out of the declarative framework into something imperative, e.g. running `apt install $package`. And that seems like it would really ease adoption, since I would assume that it would allow a gradual adoption of the declarative mindset. [1] https://wiki.c2.com/?EscapeHatch https://wiki.c2.com/?EscapeHatch

mason55 5y ago
IMO the escape hatch doesn't get you any real benefits. It's not like you can install packages from apt/yum/aur so you don't get access to any new software (plus nixpkgs is bigger than all those). All it does is result in confusing tutorials that hide the benefits of declarative management and make it difficult for new users who just want to get things working.
- chriswarbo 5y ago
  > It's not like you can install packages from apt/yum/aur Yes you can. Here's a Nix derivation which makes a Debian chroot and runs 'apt-get update; apt-get install -y chromium' https://github.com/Warbo/warbo-utilities/blob/7087c3b46a97f3fe0280cb0da74b265558856b14/scripts/in-chromium-env.nix https://github.com/Warbo/warbo-utilities/blob/7087c3b46a97f3... Here a Nix derivation for a helper script that runs the above chromium: https://github.com/Warbo/warbo-utilities/blob/7087c3b46a97f3fe0280cb0da74b265558856b14/scripts/chromium-launcher.nix https://github.com/Warbo/warbo-utilities/blob/7087c3b46a97f3... On a similar note, here's a Nix derivation for Mozilla's Firefox binary (in an FHS env), along with a warning if it's not the latest version: http://chriswarbo.net/git/warbo-packages/git/branches/master/packages/firefoxBinary.nix.raw.html http://chriswarbo.net/git/warbo-packages/git/branches/master... I wrote these once cache.nixos.org stopped providing "non-core" i686 binaries a few years ago, and I can't be bothered to build those large applications from source.
  - mason55 5y ago
    Oh yeah, great point! I was thinking of installing packages from apt/yum/aur directly with something like nix-env, but you're right, there's no reason you can't just use apt-get directly.
kevincox 5y ago
It does for some things. For example you can run `nix-env -iA firefox` to install firefox (for your user) without changing the config. (Or even better `nix run nixos.firefox -c firefox` to run it without installing) However some things like adding/editing files in /etc is a lot harder as those paths are basically recreated on boot.
chriswarbo 5y ago
A few things which might count as "escape hatches": The `runCommand` function lets us define a "package" by just executing bash code. This avoids all the "phase" machinery that most nixpkgs definitions use (those phases are great for fine-grained overriding; but we don't usually needed to override our own definitions). It takes 3 arguments: the output name, a set of env vars (including `buildInputs` which will populate $PATH) and a string of bash code (which can be multi-line using ''two quotes''): $ nix-build -E '(with import <nixpkgs> {}; runCommand "hello.txt" { buildInputs = [ foo bar baz ]; } "echo hello > $out")' these derivations will be built: /nix/store/z6ffwc1jb70zwz2ly42gaalxnvm7q0gk-hello.txt.drv building '/nix/store/z6ffwc1jb70zwz2ly42gaalxnvm7q0gk-hello.txt.drv'... /nix/store/l6sd75hj4854pdzv4044ma42axc2v5v4-hello.txt The sandbox can be selectively disabled (via whitelists), or turned off altogether, which allows builders to access arbitrary filesystem locations and the network. For example, if we have a Python pip project, and we want to take a baby step towards Nix, we could do this (assuming the sandbox is disabled): with import <nixpkgs> {}; runCommand "my-app" { buildInputs = [ (python3.withPackages (p: [ p.pip ])) ]; } '' echo "Making mutable copy of app" 1>&2 cp -r ${./.} "$out" chmod +x -R "$out" echo "Putting dependencies in place" 1>&2 pip3 install -r ${./requirements.txt} --target "$out"/ '' There are all sorts of other tricks. For example, Nix will make immutable copies of files if we reference them directly like ./foo (these copies are stored in /nix/store). If we don't want that, we can reference a symlink instead, since the resulting "immutable snapshot" is just a link to our mutable, non-/nix/store path. We can avoid having to hard-code hashes for "fixed output derivations" (like downloaded URLs) by overriding their `outputHash`, `outputHashAlgo`, `outputHashMode` and `sha256` to `null`. I wrote up a bunch of these sorts of hacks at http://chriswarbo.net/projects/nixos/useful_hacks.html http://chriswarbo.net/projects/nixos/useful_hacks.html (although its a few years old, so might not be up to date) Of course, these things aren't advisable; but they're very useful to get up and running quickly, and things can be made "more Nixy" later.
pxc 5y ago
nix-env isn't meaningfully an escape hatch, since you can still only use it with stuff that's packaged in Nix's peculiar way. Here's an overview of the escape hatches that are currently around in NixOS for package management, meaning you can use them to avoid packaging something natively for Nix, or to run pre-built software for other distros or targeting multiple distros: • flatpak — use flatpak to install stuff just like you would on any other distro: https://nixos.org/manual/nixos/stable/index.html#module-services-flatpak https://nixos.org/manual/nixos/stable/index.html#module-serv... • FHS user environments — create a usermode chroot that puts Nix packages where naive `./configure; make; make install` programs will expect to see their dependencies • steam-run — run whatever in the pre-built FHSUserEnv that Nixpkgs uses for Steam: https://nixos.org/manual/nixpkgs/stable/#sec-steam-run https://nixos.org/manual/nixpkgs/stable/#sec-steam-run • AppImage — launch an AppImage using `appimage-run` or create a quick and dirty Nix package that wrapps an existing AppImage: https://nixos.org/manual/nixpkgs/stable/#sec-pkgs-appimageTools https://nixos.org/manual/nixpkgs/stable/#sec-pkgs-appimageTo... • Docker — you can run stuff with Docker if ya want: https://search.nixos.org/options?channel=unstable&show=virtualisation.docker.enable&from=0&size=50&sort=relevance&query=docker.enable https://search.nixos.org/options?channel=unstable&show=virtu... NixOS also includes little escape hatches on the configuration side for every service. Basically every module also has an ‘extraConfig’ type of option, which lets you append to the config file that NixOS generates for the service in its original/raw format. Otherwise, you're generally looking at setting up a chroot environment. I can think of some ways that NixOS could be a little more generous with escape hatches, but I don't think there's much developer interest in the community.
- mason55 5y ago
  > Basically every module also has an ‘extraConfig’ type of option This is actually changing so that the additional config can be merged/validated even if it can't be typed https://github.com/NixOS/rfcs/blob/master/rfcs/0042-config-option.md https://github.com/NixOS/rfcs/blob/master/rfcs/0042-config-o...
  - pxc 5y ago
    This is pretty exciting! In this case, users will retain an 'escape hatch' in the sense that they'll be free to descend from whatever higher-level configuration options a module author wants to offer (which could set multiple settings, or generate settings based on other settings) and use all the configuration primitives offered by the underlying software being configured. We just won't have to manage it as a big, dumb string anymore. :D I suppose this could still be annoying for someone who really just wants to copy/paste, though.

Nullabillity 5y ago

> Even something that should be Nix's MAJOR selling point, like "create a single repo that configures a bunch of machines, including some NixOS and some other OS" doesn't have a recommended way to do it. NixOps[0]? But yeah, it isn't featured as prominently anymore as it used to be... [0]: https://github.com/NixOS/nixops https://github.com/NixOS/nixops

mason55 5y ago
NixOps is fine for pushing changes to machines (well, actually I think it has a lot of problems, and somehow the NixOps docs are even worse than the regular Nix docs as far as getting started and bootstrapping and doing basic tasks, but that's not the point). But it's all about the mechanics of pushing changes to your hosts. It certainly doesn't give you any kind of opinion on how to, say, structure a repo that has your hardware configs, Home Manager on a non-NixOS machine, Home Manager on a NixOS machine, some systemd services, etc. And there's no reason to need NixOps to maintain a repo of three or four physical machines that you have around your house.
- squiggleblaz 5y ago
  > And there's no reason to need NixOps to maintain a repo of three or four physical machines that you have around your house. You don't. You can use `nixos-rebuild test --target-host=red --flake .#red`. If you want to build locally, add --build-host=localhost. NixOps gives you the advantage of not having to repeat yourself, but you could easily whip up a shell script for `rebuild-switch red`.