6 ms·

Yes, and Nix can still lose on maintainability in the long run, considering it is more difficult to onboard new devs with it. They have to learn the Nix express

Yes, and Nix can still lose on maintainability in the long run, considering it is more difficult to onboard new devs with it. They have to learn the Nix expression language and write custom bindings for much software instead of calling the native package manager inside Docker.

CameronNemo 5y ago
I don't understand how these are comparable. I also don't understand what you mean by "bindings". Do you mean writing nix derivations for new packages? I would much rather do that than fiddle with Debian packaging. Or do you mean writing nix modules to configure a service? There are certainly some (IMO) over engineered nixos modules, but there are also some dead simple ones.
- lolpython 5y ago
  > I don't understand how these are comparable They fulfill similar business functions - allowing you to run the same code on a bunch of dev machines and on prod (modulo modifications for e.g. database storage in Docker's case). Nix people get hung up on the fact that Docker runs containers, but it doesn't really matter that much. Often Docker is the shortest path to getting software running on multiple machines reproducibly. > I also don't understand what you mean by "bindings" I am referring to derivations and modules. Both are glue that you have to write for existing software that is already packaged. With Docker you leverage the existing packaging ecosystem like pip or apt. The packages are already written for you, and you can follow the installation instructions from a project repository and they translate seamlessly into Docker. For example with ML & Python - If you want PyTorch with CUDA support, you can follow the official documentation [0] and basically copy and paste the installation instructions to a Dockerfile RUN statements. If anything breaks you can file an issue on the PyTorch issue tracker which has a wide audience. With Nix you have to write glue on top of the installation yourself, or a maintainer does it with a much smaller code review and support audience. Sometimes the audience is just the author, given that Nix project people commit directly to master frequently and do self-merges of PRs [1]. And there are other hurdles like compiling Python C extensions, which are pervasive. Another example is with software systems, I guess this would be a Nix module. Here's GitLab: [2] where it was really difficult to translate the services into Nix. But a lot of company internal services can look like GitLab with a mix-mash of odd dependencies and languages. And writing a Dockerfile for this is much easier than Nix, since you can copy from the existing README specifying the Debian or language-specific dependencies. (edit: and if there are conflicts between dependencies of the services they can go into different containers. Getting the benefit of Nix - reproducibility - without the extra effort.) [0]: https://pytorch.org/get-started/locally/ https://pytorch.org/get-started/locally/ [1]: https://discourse.nixos.org/t/proposal-require-pr-authors-to-review-other-prs/16242 https://discourse.nixos.org/t/proposal-require-pr-authors-to... [2]: https://news.ycombinator.com/item?id=14717852 https://news.ycombinator.com/item?id=14717852
  - chriswarbo 5y ago
    > With Docker you leverage the existing packaging ecosystem like pip or apt. with import <nixpkgs> {}; runCommand "my-python-package" { buildInputs = [ pythonPackages.pip ]; } '' cd ${/my/project/dir} pip install ''
    - iterati 5y ago
      That compared to `RUN pip install <package>` is probably one of the things people are complaining about, no?
      - chriswarbo 5y ago
        I think the complaint is about things like: (import <nixpkgs> {}).pythonPackages.callPackage ({ buildPythonPackage, dep1, dep2, dep3, pip }: buildPythonPackage { pname = "my-package"; version = "123"; propagatedBuildInputs = [ dep1 dep2 dep3 ]; doCheck = true; src = /my/package/dir; }) {} That's how Nixpkgs tends to do things, which has nice features like building each dependency separately, allowing easy overrides, etc. but it requires knowledge of how Nixpkgs orchestrates its Python packages. In contrast, 'runCommand' lets us just run a shell script like 'pip install', which is easier but doesn't have those niceties. Also, depending on the platform, the Nix sandbox may have to be disabled for 'pip install' to work, since Nix tries to prevent network access (I think it's enabled by default on Linux, but not on macOS)
  - soraminazuki 5y ago
    > and if there are conflicts between dependencies of the services they can go into different containers. Getting the benefit of Nix - reproducibility - without the extra effort To be clear, are you suggesting that RUN sudo apt-get update && sudo apt-get -y install ... is somehow reproducible? I'm asking because I was surprised to see the above as being described as "reproducible" of all things. Splitting that into many different containers would likely exacerbate the reproducibility problem instead of improving it. > With Docker you leverage the existing packaging ecosystem like pip or apt. The packages are already written for you This is even more true for Nix, which has the largest and most up-to-date package repositories out there[1]. Plus, with Nix, you can easily make a new package based on existing packages with a mere few lines of code if the existing packages doesn't fit your needs. Other package managers besides Guix doesn't offer you that flexibility so you'd have to compile from scratch. That's way more tedious, hard to maintain, and definitely not reproducible. [1]: https://repology.org/repositories/graphs https://repology.org/repositories/graphs

CameronNemo 5y ago

I don't understand how these are comparable. I also don't understand what you mean by "bindings". Do you mean writing nix derivations for new packages? I would much rather do that than fiddle with Debian packaging. Or do you mean writing nix modules to configure a service? There are certainly some (IMO) over engineered nixos modules, but there are also some dead simple ones.

lolpython 5y ago
> I don't understand how these are comparable They fulfill similar business functions - allowing you to run the same code on a bunch of dev machines and on prod (modulo modifications for e.g. database storage in Docker's case). Nix people get hung up on the fact that Docker runs containers, but it doesn't really matter that much. Often Docker is the shortest path to getting software running on multiple machines reproducibly. > I also don't understand what you mean by "bindings" I am referring to derivations and modules. Both are glue that you have to write for existing software that is already packaged. With Docker you leverage the existing packaging ecosystem like pip or apt. The packages are already written for you, and you can follow the installation instructions from a project repository and they translate seamlessly into Docker. For example with ML & Python - If you want PyTorch with CUDA support, you can follow the official documentation [0] and basically copy and paste the installation instructions to a Dockerfile RUN statements. If anything breaks you can file an issue on the PyTorch issue tracker which has a wide audience. With Nix you have to write glue on top of the installation yourself, or a maintainer does it with a much smaller code review and support audience. Sometimes the audience is just the author, given that Nix project people commit directly to master frequently and do self-merges of PRs [1]. And there are other hurdles like compiling Python C extensions, which are pervasive. Another example is with software systems, I guess this would be a Nix module. Here's GitLab: [2] where it was really difficult to translate the services into Nix. But a lot of company internal services can look like GitLab with a mix-mash of odd dependencies and languages. And writing a Dockerfile for this is much easier than Nix, since you can copy from the existing README specifying the Debian or language-specific dependencies. (edit: and if there are conflicts between dependencies of the services they can go into different containers. Getting the benefit of Nix - reproducibility - without the extra effort.) [0]: https://pytorch.org/get-started/locally/ https://pytorch.org/get-started/locally/ [1]: https://discourse.nixos.org/t/proposal-require-pr-authors-to-review-other-prs/16242 https://discourse.nixos.org/t/proposal-require-pr-authors-to... [2]: https://news.ycombinator.com/item?id=14717852 https://news.ycombinator.com/item?id=14717852
- chriswarbo 5y ago
  > With Docker you leverage the existing packaging ecosystem like pip or apt. with import <nixpkgs> {}; runCommand "my-python-package" { buildInputs = [ pythonPackages.pip ]; } '' cd ${/my/project/dir} pip install ''
  - iterati 5y ago
    That compared to `RUN pip install <package>` is probably one of the things people are complaining about, no?
    - chriswarbo 5y ago
      I think the complaint is about things like: (import <nixpkgs> {}).pythonPackages.callPackage ({ buildPythonPackage, dep1, dep2, dep3, pip }: buildPythonPackage { pname = "my-package"; version = "123"; propagatedBuildInputs = [ dep1 dep2 dep3 ]; doCheck = true; src = /my/package/dir; }) {} That's how Nixpkgs tends to do things, which has nice features like building each dependency separately, allowing easy overrides, etc. but it requires knowledge of how Nixpkgs orchestrates its Python packages. In contrast, 'runCommand' lets us just run a shell script like 'pip install', which is easier but doesn't have those niceties. Also, depending on the platform, the Nix sandbox may have to be disabled for 'pip install' to work, since Nix tries to prevent network access (I think it's enabled by default on Linux, but not on macOS)
- soraminazuki 5y ago
  > and if there are conflicts between dependencies of the services they can go into different containers. Getting the benefit of Nix - reproducibility - without the extra effort To be clear, are you suggesting that RUN sudo apt-get update && sudo apt-get -y install ... is somehow reproducible? I'm asking because I was surprised to see the above as being described as "reproducible" of all things. Splitting that into many different containers would likely exacerbate the reproducibility problem instead of improving it. > With Docker you leverage the existing packaging ecosystem like pip or apt. The packages are already written for you This is even more true for Nix, which has the largest and most up-to-date package repositories out there[1]. Plus, with Nix, you can easily make a new package based on existing packages with a mere few lines of code if the existing packages doesn't fit your needs. Other package managers besides Guix doesn't offer you that flexibility so you'd have to compile from scratch. That's way more tedious, hard to maintain, and definitely not reproducible. [1]: https://repology.org/repositories/graphs https://repology.org/repositories/graphs