6 ms·

My experience with NixOS: Package installation is usually just from the official channel, system options can usually be done with `/etc/nixos/configuration.nix`

My experience with NixOS: Package installation is usually just from the official channel, system options can usually be done with `/etc/nixos/configuration.nix` and home-manager. Major problems: installing niche proprietary software that you may have to package yourself, and fighting Nix for languages with package manager, e.g. Python, which frequently uses packages not in nixpkgs.

sleepycatgirl 4y ago
For niche software, I found steam-run, or distrobox As for last problem.. Yeah. It is a problem. x.x
- SuperSandro2000 4y ago
  steam-run is just a fat wrapper around bubblewrap fhs. If you want to optimize your system you can easily build a smaller one yourself.
SuperSandro2000 4y ago
nixpkgs is already one of the largest package collections. There is a good chance your software is already included. The nix language itself is pretty straightforward and if you know haskell your should feel straight at home. You shouldn't use nixpkgs python packages as a replacement for your python development. That would also not work that great on other distros.
- suprfnk 4y ago
  > nixpkgs is already one of the largest package collections. There is a good chance your software is already included. Yes, but that still doesn't solve this: > Major problems: installing niche proprietary software that you may have to package yourself If some software _isn't_ packaged, it's a pain in the butt to get it running on NixOS. Either you have to create Nix derivations, which have a pretty steep learning curve, or you have to do some hackery patchelf business, which also isn't easy. At least, as of 2018, when I last tried. Things could be better now.
  - SuperSandro2000 4y ago
    Creating a basic nix derivation is easy and if you don't want to upstream it you can take all kinds of dirty and impure shortcuts. You almost never want to invoke patchelf by itself but use some wrapper like autoPatchelfHook, FHS, nix-ld, nix-autobahn, etc. Since 2018 a lot quite a lot happened. Give it another chance.
    - thomastjeffery 4y ago
      It's only way when you know how. It's quite difficult to learn.
  - thomastjeffery 4y ago
    It's more a story of, you have to do some hackery patchelf business, but creating a Nix derivation helps you do just that. The unfortunate part is that creating a Nix derivation is no more approachable than the patchelf hackery was in the first place.
    - SuperSandro2000 4y ago
      Most of the time you can just use autoPatchElfHook and add the missing libraries to buildInputs. I can't remember when I last looked at patchelf itself.
      - thomastjeffery 4y ago
        ...and learning that is the hard part.
  - pmarreck 4y ago
    I run NixOS, but I'm relatively new to Nix. A couple weeks ago I was trying to get an old vanity key generator to build because it wasn't on nixpkgs (vanitygen++) and on a lark I decided to write my own derivation using some examples of similar C++ packages I found and figuring out what nix packages it needed to build. So I did, and the maintainer accepted the PR: https://github.com/10gic/vanitygen-plusplus/commit/7bcee06f3a9a718158bd8adebc3bee0286d41547 https://github.com/10gic/vanitygen-plusplus/commit/7bcee06f3... Note that I am not a C++ developer and only know the basics about how to get C/C++ things to build. So what does this get us? In theory, this is now trivially-buildable on any distro that has nix installed, or on nixos. I haven't converted it to a flake yet (still learning that) but if I (or someone else) did, it would be deterministically reproducible anywhere on nix. I agree that there's a learning curve on figuring out the "recipe" for a thing, but once someone does that work, it's basically done forever. Which is a promise that no other system can even approach. And once you figure out a certain amount of it, this moment will come where you realize you want every system you deal with to be Nixified. Like the guy elsewhere in this thread who rebuilt his own router using NixOS and loves it. Getting new developers up to speed in your shop's dev environment? Completely trivial to do with Nix. Getting a machine back up after a failure? Reinstall NixOS and reapply the config you were using (which is in source control). Upgraded Gnome and some things you need broke? Or updated your GPU driver and now your screen just shows black? Simple... Roll back in the bootloader to a previously-working config, then undo your changes to the config definition. Have 10 different projects all with different dependencies and version requirements that would normally collide with each other? Trivial, each project has its own default.nix file and Nix can drop you right into that environment while you're working on those projects. NixOS (and very honorable mention to Guix) are in fact the only ways to run Linux while keeping your sanity intact!
- yorwba 4y ago
  It would be nice if you could just install python packages with pip in a venv and ignore nixpkgs python packages, but then some things like e.g. pyqt5 actually have some extra dependencies on system libraries, so you pretty much need the nixpkgs version to get it to run https://nixos.wiki/wiki/Packaging/Quirks_and_Caveats#ImportError:_libstdc.2B.2B.so.6:_cannot_open_shared_object_file:_No_such_file https://nixos.wiki/wiki/Packaging/Quirks_and_Caveats#ImportE... and if you want to keep using the venv for the other packages (e.g. because they aren't in nixpkgs) you might try initializing with "python3 -m venv --system-site-packages" to make the nixpkgs pyqt5 visible in the venv, but for some reason venv/bin/python3 ends up pointing to the wrong python, so I currently resort to "ln -s $(readlink -e $(which python3)) venv/bin/python3" ... If there's some easier way, I'm eager to hear about it.
- pca006132 4y ago
  I think there are a few problems here: 1. Packaging requires knowing more than just the language, you should also know how files are being linked, what to look for when you got an error. If you only know haskell, you may not know this. 2. If you wrote the correct script, it just works. But if you wrote something wrong but syntactically correct, finding the issue may not be that trivial, in my experience the trace is not very useful. 3. Not sure where the documentation for helper functions is. I think there are unofficial documentation out there but iirc it is not in the nix reference manual? 4. Some python packages with system dependencies will not work when installed through virtual environment. I haven't done serious python development for a long time so I forgot what I usually do to fix it, but I think I just packaged everything in Nix. 5. Some build tools without wrapper (iirc mold, ldd) will cause loader error. But yeah, I do agree that packaging is not that hard, just require a bit more thoughts than just using typical build instructions and `make install`, and perhaps look at the binaries with ldd.
  - SuperSandro2000 4y ago
    1. Yes, you need to know some more things but in particular not linking. I have no idea about linking or what to do when it fails with weird symbol errors. If you have a standard autotools, cmake or meson setup it might be as easy as just adding the packages to nativeBuildInputs and it works. The more custom stuff the project does the more you need to hold it hands. 3. For example here https://nixos.org/manual/nixpkgs/unstable/#chap-hooks https://nixos.org/manual/nixpkgs/unstable/#chap-hooks 5. It is quite the opposite. If the typical build instructions are ./configure; make; make install then you might only need to specify the install directory to $out and you are done. Looking at ldd is also not usually required when compiling from source.
    - pmarreck 4y ago
      FYI this comment ended up making something work that I couldn't get working (as a side project) for at least 2 months; I did not realize that providing certain things as nativeBuildInputs might make package sub-dependencies build correctly (so for example, I have an Elixir project which depends on a NIF which is a compiled C++ or Rust project which is automatically built when I build the main Elixir project). Moving those to that suddenly made it work! So thank you for that! There's not a lot of docs I found out there (yet?) about getting sub- or sub-sub-dependencies to build correctly in multi-layered projects that depend on different language technologies and build toolchains (where a traditional linux distro makes A LOT of assumptions that "just so happen" to work!), but at least now that I got this working, I can lock it down with a flake and in theory be good to go for a while! (or at least have a rollback strategy if something borks!)
- seqizz 4y ago
  > .. if you know haskell .. And if you don't have any FP background you're just.. out of luck. /s
  - SuperSandro2000 4y ago
    I must admit I got a long way with contributing without knowing much about functional programming. Most things done in mkDerivation especially the basic ones almost abstract the functional and lazy part away.
colordrops 4y ago
I wouldn't call them major problems. There are workarounds for running things without much effort if you want, e.g. FHS or steam run or distro box. For Python, you can create a virtual env and use it like any other machine. And if you do put in the effort to make a package, you'll never have problems figuring out how to install it in the future, and can share that gain with others. Making packages for nix is way easier than making debs or rpms in my experience.
- notemaker 4y ago
  Some packages won't work when installed via pip though, psycopg2 for instance.
  - ochoseis 4y ago
    Occasionally you can get packages with native dependencies to work by creating a nix shell that includes the dependent libraries. Sometimes that can mean using an FHS shell, which is indeed annoying. It’s not elegant, but you can also usually find popular Python libraries in nixpkgs so they’re available in your shell’s “global” Python environment.
ar_lan 4y ago
> Major problems I don't think I agree here. There are plenty of examples of how to package/update/fix anything custom you desire. The learning curve is there, definitely, but this is not major - I do this several times for my own OS and software that utilizes Nix.

sleepycatgirl 4y ago

For niche software, I found steam-run, or distrobox As for last problem.. Yeah. It is a problem. x.x

SuperSandro2000 4y ago
steam-run is just a fat wrapper around bubblewrap fhs. If you want to optimize your system you can easily build a smaller one yourself.

SuperSandro2000 4y ago

nixpkgs is already one of the largest package collections. There is a good chance your software is already included. The nix language itself is pretty straightforward and if you know haskell your should feel straight at home. You shouldn't use nixpkgs python packages as a replacement for your python development. That would also not work that great on other distros.

suprfnk 4y ago
> nixpkgs is already one of the largest package collections. There is a good chance your software is already included. Yes, but that still doesn't solve this: > Major problems: installing niche proprietary software that you may have to package yourself If some software _isn't_ packaged, it's a pain in the butt to get it running on NixOS. Either you have to create Nix derivations, which have a pretty steep learning curve, or you have to do some hackery patchelf business, which also isn't easy. At least, as of 2018, when I last tried. Things could be better now.
- SuperSandro2000 4y ago
  Creating a basic nix derivation is easy and if you don't want to upstream it you can take all kinds of dirty and impure shortcuts. You almost never want to invoke patchelf by itself but use some wrapper like autoPatchelfHook, FHS, nix-ld, nix-autobahn, etc. Since 2018 a lot quite a lot happened. Give it another chance.
  - thomastjeffery 4y ago
    It's only way when you know how. It's quite difficult to learn.
- thomastjeffery 4y ago
  It's more a story of, you have to do some hackery patchelf business, but creating a Nix derivation helps you do just that. The unfortunate part is that creating a Nix derivation is no more approachable than the patchelf hackery was in the first place.
  - SuperSandro2000 4y ago
    Most of the time you can just use autoPatchElfHook and add the missing libraries to buildInputs. I can't remember when I last looked at patchelf itself.
    - thomastjeffery 4y ago
      ...and learning that is the hard part.
- pmarreck 4y ago
  I run NixOS, but I'm relatively new to Nix. A couple weeks ago I was trying to get an old vanity key generator to build because it wasn't on nixpkgs (vanitygen++) and on a lark I decided to write my own derivation using some examples of similar C++ packages I found and figuring out what nix packages it needed to build. So I did, and the maintainer accepted the PR: https://github.com/10gic/vanitygen-plusplus/commit/7bcee06f3a9a718158bd8adebc3bee0286d41547 https://github.com/10gic/vanitygen-plusplus/commit/7bcee06f3... Note that I am not a C++ developer and only know the basics about how to get C/C++ things to build. So what does this get us? In theory, this is now trivially-buildable on any distro that has nix installed, or on nixos. I haven't converted it to a flake yet (still learning that) but if I (or someone else) did, it would be deterministically reproducible anywhere on nix. I agree that there's a learning curve on figuring out the "recipe" for a thing, but once someone does that work, it's basically done forever. Which is a promise that no other system can even approach. And once you figure out a certain amount of it, this moment will come where you realize you want every system you deal with to be Nixified. Like the guy elsewhere in this thread who rebuilt his own router using NixOS and loves it. Getting new developers up to speed in your shop's dev environment? Completely trivial to do with Nix. Getting a machine back up after a failure? Reinstall NixOS and reapply the config you were using (which is in source control). Upgraded Gnome and some things you need broke? Or updated your GPU driver and now your screen just shows black? Simple... Roll back in the bootloader to a previously-working config, then undo your changes to the config definition. Have 10 different projects all with different dependencies and version requirements that would normally collide with each other? Trivial, each project has its own default.nix file and Nix can drop you right into that environment while you're working on those projects. NixOS (and very honorable mention to Guix) are in fact the only ways to run Linux while keeping your sanity intact!
yorwba 4y ago
It would be nice if you could just install python packages with pip in a venv and ignore nixpkgs python packages, but then some things like e.g. pyqt5 actually have some extra dependencies on system libraries, so you pretty much need the nixpkgs version to get it to run https://nixos.wiki/wiki/Packaging/Quirks_and_Caveats#ImportError:_libstdc.2B.2B.so.6:_cannot_open_shared_object_file:_No_such_file https://nixos.wiki/wiki/Packaging/Quirks_and_Caveats#ImportE... and if you want to keep using the venv for the other packages (e.g. because they aren't in nixpkgs) you might try initializing with "python3 -m venv --system-site-packages" to make the nixpkgs pyqt5 visible in the venv, but for some reason venv/bin/python3 ends up pointing to the wrong python, so I currently resort to "ln -s $(readlink -e $(which python3)) venv/bin/python3" ... If there's some easier way, I'm eager to hear about it.
pca006132 4y ago
I think there are a few problems here: 1. Packaging requires knowing more than just the language, you should also know how files are being linked, what to look for when you got an error. If you only know haskell, you may not know this. 2. If you wrote the correct script, it just works. But if you wrote something wrong but syntactically correct, finding the issue may not be that trivial, in my experience the trace is not very useful. 3. Not sure where the documentation for helper functions is. I think there are unofficial documentation out there but iirc it is not in the nix reference manual? 4. Some python packages with system dependencies will not work when installed through virtual environment. I haven't done serious python development for a long time so I forgot what I usually do to fix it, but I think I just packaged everything in Nix. 5. Some build tools without wrapper (iirc mold, ldd) will cause loader error. But yeah, I do agree that packaging is not that hard, just require a bit more thoughts than just using typical build instructions and `make install`, and perhaps look at the binaries with ldd.
- SuperSandro2000 4y ago
  1. Yes, you need to know some more things but in particular not linking. I have no idea about linking or what to do when it fails with weird symbol errors. If you have a standard autotools, cmake or meson setup it might be as easy as just adding the packages to nativeBuildInputs and it works. The more custom stuff the project does the more you need to hold it hands. 3. For example here https://nixos.org/manual/nixpkgs/unstable/#chap-hooks https://nixos.org/manual/nixpkgs/unstable/#chap-hooks 5. It is quite the opposite. If the typical build instructions are ./configure; make; make install then you might only need to specify the install directory to $out and you are done. Looking at ldd is also not usually required when compiling from source.
  - pmarreck 4y ago
    FYI this comment ended up making something work that I couldn't get working (as a side project) for at least 2 months; I did not realize that providing certain things as nativeBuildInputs might make package sub-dependencies build correctly (so for example, I have an Elixir project which depends on a NIF which is a compiled C++ or Rust project which is automatically built when I build the main Elixir project). Moving those to that suddenly made it work! So thank you for that! There's not a lot of docs I found out there (yet?) about getting sub- or sub-sub-dependencies to build correctly in multi-layered projects that depend on different language technologies and build toolchains (where a traditional linux distro makes A LOT of assumptions that "just so happen" to work!), but at least now that I got this working, I can lock it down with a flake and in theory be good to go for a while! (or at least have a rollback strategy if something borks!)
seqizz 4y ago
> .. if you know haskell .. And if you don't have any FP background you're just.. out of luck. /s
- SuperSandro2000 4y ago
  I must admit I got a long way with contributing without knowing much about functional programming. Most things done in mkDerivation especially the basic ones almost abstract the functional and lazy part away.

colordrops 4y ago

I wouldn't call them major problems. There are workarounds for running things without much effort if you want, e.g. FHS or steam run or distro box. For Python, you can create a virtual env and use it like any other machine. And if you do put in the effort to make a package, you'll never have problems figuring out how to install it in the future, and can share that gain with others. Making packages for nix is way easier than making debs or rpms in my experience.

notemaker 4y ago
Some packages won't work when installed via pip though, psycopg2 for instance.
- ochoseis 4y ago
  Occasionally you can get packages with native dependencies to work by creating a nix shell that includes the dependent libraries. Sometimes that can mean using an FHS shell, which is indeed annoying. It’s not elegant, but you can also usually find popular Python libraries in nixpkgs so they’re available in your shell’s “global” Python environment.

ar_lan 4y ago

> Major problems I don't think I agree here. There are plenty of examples of how to package/update/fix anything custom you desire. The learning curve is there, definitely, but this is not major - I do this several times for my own OS and software that utilizes Nix.