6 ms·

NixOS doesn't have directories like /usr/bin, /etc, etc. This defeats the traditional `make && make install` path; instead you have to build a nix package, and

NixOS doesn't have directories like /usr/bin, /etc, etc. This defeats the traditional `make && make install` path; instead you have to build a nix package, and be familiar with stdenv. My concern is that it would be more difficult to install software that doesn't have a nix package built (in particular, from git repo trunks), and also more difficult to have confidence that the software I write would work on other Linux distros. For this reason I chose Arch over NixOS. In practice NixOS users find these to be significant issues? How do you deal with them?

bennofs 8y ago
One way to deal with them: if you have some software package you only want to build as quick as possible and don't want to bother with any nix stuff, spawn an Ubuntu (or any other distro if the package has instructions for a certain distro) docker container and build the app within that. (Or use steam-run from NixOS which is basically an Ubuntu container) This also has the advantage that you can use the exact same distribution that the instructions for said package mention. (If the thing you want to compile has instructions for Ubuntu 16.04 no problem just use the docker image for that) For anything that you want to use on a regular basis, creating a nix package is pretty easy most of the time. If you only want to build a newer version of a package directly from git, you can even copy the package for the stable version and just overwrite the src in many cases. Regarding software that works on NixOS but not on other distros I think it's usually the other way around: by testing your software on NixOS you uncover issues that would have made your software less portable (hidden dependencies, hardcoded path assumptions, ...)
mbrock 8y ago
Making a Nix package is usually quite fun, but if the software has a really gnarly setup (various forked dependencies, strange configuration scripts that involve the internet, npm modules with native library dependencies, etc) it can be bad. For such cases I like Docker because it lets you easily create little mini-Ubuntus and do whatever you want there.
- kreetx 8y ago
  But I think if you know nix well enough then making some strange setup work might end up a better long term solution that the ubuntu, no? I.e you put in the time upfront in researching how the thing wants it at build time, and then you have the infrastructure ready should the thing change its mind in future versions. Making it build in some less flexible context can become a lot more hackish down the line.
  - joepie91_ 8y ago
    While true, the effort vs. payoff tradeoff doesn't always work out in favour of Nix there. That's largely due to lacking documentation, but I imagine there will always remain 'quick hacks' in use for things that don't need to work for an extended period of time, for example. That having been said, for anything that needs to work for a longer period of time, it's 100% worth taking apart the install process.
aseipp 8y ago
When you're doing development, you can generally use `nix-shell` to install all the pre-requisite tools. If you wanted to compile GNU hello, for example, you'd do: $ nix-shell -A hello Which will populate a temporary shell with everything you need to compile GNU hello. Then you can just do `./configure` and `make` like usual, normally. If you know an explicit list of dependencies, you can do that too, e.g. `nix-shell -p libxml2 bison flex pkg-config`, for example. Then run `make` and run `./bin/foobar`, or whatever your application is. This is OK for development cycles (`make && make test`, things like that) but not for the long term. Most of the time incremental development works just fine this way, though, especially for software you're writing or developing yourself. You just run your commands inside a `nix-shell` instead. If you want to use a Git repository for something, most of the time you can just 'override' a packages source code input to a new version. In Nix, even source code is actually an 'input' (a parameter) to a build script (a function), so you can just provide a new copy of the source code (pass a different parameter to the function) and rebuild. Of course, someones Git repository may have changed in ways that make the old build script incompatible. You can similarly override/update the build script, and there are a number of mechanisms to do this. > My concern is that it would be more difficult to install software that doesn't have a nix package built (in particular, from git repo trunks) This is true and in reality most Nix users are package authors. You will probably find things that are not packaged and you will have to author them. Occasionally, a package may not have some feature enabled (maintainers generally decide these things on their own when it comes to optional features), so you may have to fix it. Updating/custom source code versions isn't as much of a problem though. Once the Nix expression for some software is authored just pointing/updating the source repository is normally enough to do it. > and also more difficult to have confidence that the software I write would work on other Linux distros IME, if your software can work correctly on NixOS with little modification (or extremely perverted build scripts), it will almost certainly work fine anywhere else. In particular as long as your build system obeys "standard rules" like supporting PREFIX and respecting things like `pkg-config`, not hardcoding binary paths everywhere but detecting them, it will normally work just fine. cmake, autotools, pypi, etc all have pretty usable solutions for the extremely common cases. Nix can often quickly unveil assumptions in your build step that would previously be masked (for example, I cannot count the amount of READMEs that have 'apt-get' instructions for build prerequisites, which do not actually account for all the necessary dependencies.) Realistically I have authored dozens of packages and the ones that cause the most pain are ones that have complex, bespoke build systems with a lot of assumptions built in, or that don't actually specify all the dependencies they think they do, and silently get things wrong. Think packages like OpenJDK, Mono, any web browser, etc etc. Other things occasionally require some bespoke patching to get cleaner integration, even if the build system itself is otherwise nice enough (such as PostgreSQL or Linux itself.) > In practice NixOS users find these to be significant issues? How do you deal with them? They can be annoying, and I would say writing build expressions is sometimes a bit more difficult than I'd like -- but not enough to outweigh the actual advantages, which are otherwise tremendous. Normally I just author packages and submit them upstream for cases like this. In the case where a fix for some issue seems reasonable to upstream I just submit it upstream like a traditional maintainer. Not everything falls into this category, though, so, like any maintainer, you might be on the hook for it.
aidenn0 8y ago
It takes about 5 minutes to make a nix expression for a "./configure && make && make install", with most of that time being figuring out the dependencies and calculating the checksum of the tarball. Example: https://nixos.org/nix/manual/#ex-hello-nix https://nixos.org/nix/manual/#ex-hello-nix For any standard build tools (cmake, scons, whatever) it's just one extra line. Applying patches is one extra line. For a non-standard workflow, you can supply a shell script for each step (unpack, configure, build, install, &c.). so it's just however many lines that is. I've had zero issue getting any source-based third party stuff running. Binaries are a pain, but that's always true if you aren't running the exact distro that the binary was built for.
- Ralith 8y ago
  > Binaries are a pain, but that's always true if you aren't running the exact distro that the binary was built for. This is actually easier to deal with on NixOS than elsewhere, because the tools for handling that case (patchelf, buildFHSUserEnv, supporting multiple versions of a lib, etc) are so well developed.
  - danieldk 8y ago
    Indeed, just two days ago I made a derivation for a large binary, which is built against an older Boost (1.58). On most other package managers, this would be painful, but with Nix I just made a derivation for that version of Boost by overriding Boost 1.59, which is in nixpkgs: https://github.com/danieldk/nix-home/blob/f6da4d02686224b3008489a743fbd558db689aef/overlays/20-alpino.nix#L4 https://github.com/danieldk/nix-home/blob/f6da4d02686224b300...
danieldk 8y ago
My concern is that it would be more difficult to install software that doesn't have a nix package built (in particular, from git repo trunks), and also more difficult to have confidence that the software I write would work on other Linux distros. For this reason I chose Arch over NixOS. I have a set of overlays for various packages and try to submit updates and improvements upstream. Having some experience with making packages for other package managers, I found making Nix derivations easier than RPM or deb packages and about as difficult as Arch PKGBUILDs. stdenv automates a lot of work, and when a package uses a standardized configuration/build system (autotools, cmake, cargo), most of the work is in finding/adding the dependencies. I did some Haskell programming ~6-7 years ago, so the learning curve for the Nix language was probably less steep. The primary difficulty I found is that not everything is documented equally well and you often have to poke through nixpkgs to find examples and/or good practices. also more difficult to have confidence that the software I write would work on other Linux distros I guess I have been lucky that I write work-related code mostly in Go and Rust, so building on other systems is never really a problem. But for C/C++ projects I would just compile in an Ubuntu container as well.
- Ralith 8y ago
  > But for C/C++ projects I would just compile in an Ubuntu container as well. Setting up a reproducible build environment with nix-shell is much more convenient than screwing around with containers.
  - danieldk 8y ago
    I meant to test outside NixOS. I already use default.nix + direnv for my C++ projects.

bennofs 8y ago

One way to deal with them: if you have some software package you only want to build as quick as possible and don't want to bother with any nix stuff, spawn an Ubuntu (or any other distro if the package has instructions for a certain distro) docker container and build the app within that. (Or use steam-run from NixOS which is basically an Ubuntu container) This also has the advantage that you can use the exact same distribution that the instructions for said package mention. (If the thing you want to compile has instructions for Ubuntu 16.04 no problem just use the docker image for that) For anything that you want to use on a regular basis, creating a nix package is pretty easy most of the time. If you only want to build a newer version of a package directly from git, you can even copy the package for the stable version and just overwrite the src in many cases. Regarding software that works on NixOS but not on other distros I think it's usually the other way around: by testing your software on NixOS you uncover issues that would have made your software less portable (hidden dependencies, hardcoded path assumptions, ...)

mbrock 8y ago

Making a Nix package is usually quite fun, but if the software has a really gnarly setup (various forked dependencies, strange configuration scripts that involve the internet, npm modules with native library dependencies, etc) it can be bad. For such cases I like Docker because it lets you easily create little mini-Ubuntus and do whatever you want there.

kreetx 8y ago
But I think if you know nix well enough then making some strange setup work might end up a better long term solution that the ubuntu, no? I.e you put in the time upfront in researching how the thing wants it at build time, and then you have the infrastructure ready should the thing change its mind in future versions. Making it build in some less flexible context can become a lot more hackish down the line.
- joepie91_ 8y ago
  While true, the effort vs. payoff tradeoff doesn't always work out in favour of Nix there. That's largely due to lacking documentation, but I imagine there will always remain 'quick hacks' in use for things that don't need to work for an extended period of time, for example. That having been said, for anything that needs to work for a longer period of time, it's 100% worth taking apart the install process.

aseipp 8y ago

When you're doing development, you can generally use `nix-shell` to install all the pre-requisite tools. If you wanted to compile GNU hello, for example, you'd do: $ nix-shell -A hello Which will populate a temporary shell with everything you need to compile GNU hello. Then you can just do `./configure` and `make` like usual, normally. If you know an explicit list of dependencies, you can do that too, e.g. `nix-shell -p libxml2 bison flex pkg-config`, for example. Then run `make` and run `./bin/foobar`, or whatever your application is. This is OK for development cycles (`make && make test`, things like that) but not for the long term. Most of the time incremental development works just fine this way, though, especially for software you're writing or developing yourself. You just run your commands inside a `nix-shell` instead. If you want to use a Git repository for something, most of the time you can just 'override' a packages source code input to a new version. In Nix, even source code is actually an 'input' (a parameter) to a build script (a function), so you can just provide a new copy of the source code (pass a different parameter to the function) and rebuild. Of course, someones Git repository may have changed in ways that make the old build script incompatible. You can similarly override/update the build script, and there are a number of mechanisms to do this. > My concern is that it would be more difficult to install software that doesn't have a nix package built (in particular, from git repo trunks) This is true and in reality most Nix users are package authors. You will probably find things that are not packaged and you will have to author them. Occasionally, a package may not have some feature enabled (maintainers generally decide these things on their own when it comes to optional features), so you may have to fix it. Updating/custom source code versions isn't as much of a problem though. Once the Nix expression for some software is authored just pointing/updating the source repository is normally enough to do it. > and also more difficult to have confidence that the software I write would work on other Linux distros IME, if your software can work correctly on NixOS with little modification (or extremely perverted build scripts), it will almost certainly work fine anywhere else. In particular as long as your build system obeys "standard rules" like supporting PREFIX and respecting things like `pkg-config`, not hardcoding binary paths everywhere but detecting them, it will normally work just fine. cmake, autotools, pypi, etc all have pretty usable solutions for the extremely common cases. Nix can often quickly unveil assumptions in your build step that would previously be masked (for example, I cannot count the amount of READMEs that have 'apt-get' instructions for build prerequisites, which do not actually account for all the necessary dependencies.) Realistically I have authored dozens of packages and the ones that cause the most pain are ones that have complex, bespoke build systems with a lot of assumptions built in, or that don't actually specify all the dependencies they think they do, and silently get things wrong. Think packages like OpenJDK, Mono, any web browser, etc etc. Other things occasionally require some bespoke patching to get cleaner integration, even if the build system itself is otherwise nice enough (such as PostgreSQL or Linux itself.) > In practice NixOS users find these to be significant issues? How do you deal with them? They can be annoying, and I would say writing build expressions is sometimes a bit more difficult than I'd like -- but not enough to outweigh the actual advantages, which are otherwise tremendous. Normally I just author packages and submit them upstream for cases like this. In the case where a fix for some issue seems reasonable to upstream I just submit it upstream like a traditional maintainer. Not everything falls into this category, though, so, like any maintainer, you might be on the hook for it.

aidenn0 8y ago

It takes about 5 minutes to make a nix expression for a "./configure && make && make install", with most of that time being figuring out the dependencies and calculating the checksum of the tarball. Example: https://nixos.org/nix/manual/#ex-hello-nix https://nixos.org/nix/manual/#ex-hello-nix For any standard build tools (cmake, scons, whatever) it's just one extra line. Applying patches is one extra line. For a non-standard workflow, you can supply a shell script for each step (unpack, configure, build, install, &c.). so it's just however many lines that is. I've had zero issue getting any source-based third party stuff running. Binaries are a pain, but that's always true if you aren't running the exact distro that the binary was built for.

Ralith 8y ago
> Binaries are a pain, but that's always true if you aren't running the exact distro that the binary was built for. This is actually easier to deal with on NixOS than elsewhere, because the tools for handling that case (patchelf, buildFHSUserEnv, supporting multiple versions of a lib, etc) are so well developed.
- danieldk 8y ago
  Indeed, just two days ago I made a derivation for a large binary, which is built against an older Boost (1.58). On most other package managers, this would be painful, but with Nix I just made a derivation for that version of Boost by overriding Boost 1.59, which is in nixpkgs: https://github.com/danieldk/nix-home/blob/f6da4d02686224b3008489a743fbd558db689aef/overlays/20-alpino.nix#L4 https://github.com/danieldk/nix-home/blob/f6da4d02686224b300...

danieldk 8y ago

My concern is that it would be more difficult to install software that doesn't have a nix package built (in particular, from git repo trunks), and also more difficult to have confidence that the software I write would work on other Linux distros. For this reason I chose Arch over NixOS. I have a set of overlays for various packages and try to submit updates and improvements upstream. Having some experience with making packages for other package managers, I found making Nix derivations easier than RPM or deb packages and about as difficult as Arch PKGBUILDs. stdenv automates a lot of work, and when a package uses a standardized configuration/build system (autotools, cmake, cargo), most of the work is in finding/adding the dependencies. I did some Haskell programming ~6-7 years ago, so the learning curve for the Nix language was probably less steep. The primary difficulty I found is that not everything is documented equally well and you often have to poke through nixpkgs to find examples and/or good practices. also more difficult to have confidence that the software I write would work on other Linux distros I guess I have been lucky that I write work-related code mostly in Go and Rust, so building on other systems is never really a problem. But for C/C++ projects I would just compile in an Ubuntu container as well.

Ralith 8y ago
> But for C/C++ projects I would just compile in an Ubuntu container as well. Setting up a reproducible build environment with nix-shell is much more convenient than screwing around with containers.
- danieldk 8y ago
  I meant to test outside NixOS. I already use default.nix + direnv for my C++ projects.