Let me interrupt that in the middle and undo some steps by hand and it will probably fall on its nose. Nix can handle interruption in the middle of all build steps and can cleanly recover from them.
737 karma · joined August 20, 2016
/etc/nixos/configuration.nix if you haven't structured your config differently.
> And where in the file do I add those lines?
Consult `man configuration.nix` or search.nixos.org
*Nix
Yes
> A build system?
No
> An operating system?
Thats NixOS
> A container platform?
nixpkgs has functions to build them
> A sandbox?
No
> An automation tool?
Yes and no
> Which widely used, existing software tools is it analogous to?
Arch Linux plus Haskell plus Ansible plus better
No, applications that are properly maintained work as they should and this can be ensured with tests and e2e tests.
There isn't one but we are not collecting multiple package versions for no reason and since python itself cannot well handle multiple versions of packages they are only allowed outside of pythonPackages where all end user applications should live.
The whole point of NixOS is to manage this and to get rid of those manual steps that are error prone.
Yes, completely agreeing with that.
Not really, nix is way more flexible and more up to date and nix also often runs tests and different pythons cannot interfere with each other that easily. On a high level things are similar but the details are wastly different.
> Or you could create a hermetic environment, where an app gets an isolated copy of dependencies, specific just to the single app, a situation similar to using virtual env.
That could also be done with nix but is often not because upstream pin quality is often lacking.
On Linux there are far few steps: - delete /nix - delete build users (could be removed in the future) - delete she'll script files in /etc/profile - delete systemd nix-daemon service - delete symlinks in user directory