7 ms·

Since switching to nixos, my Python development environment couldn't be more satisfying. I use a default.nix file and a requirements.txt file and then with a s

Since switching to nixos, my Python development environment couldn't be more satisfying. I use a default.nix file and a requirements.txt file and then with a single command I'm into a shell and virtual environment with all dependencies and packages installed, that I can easily transfer between machines. That is unless I want to use PyQt5.

nextos 9y ago
Nix is one of the most amazing things created lately. IMHO, it doesn't get the attention it deserves as it provides great solutions to really tough problems and it's ready for prime time. A purely functional package manager, distro, devops. And pretty soon, home directory management. Maintaining servers or doing aggressive changes becomes very easy. There's even a Darwin (macOS) implementation now, so you can manage most of your Mac functionally (with heavy usage of defaults under the hood). It's still lacking a bit on usability, as some things are not as intuitive as in a simple imperative distribution such as Arch or Alpine. Especially if you need to run some prepackaged software that assumes FHS and binds dynamically to some pre-existing dependencies. But to me, right now if you are a moderately advanced user I don't see a point in running distros that are stuck in the middle (imperative, complex, lots of defaults). It's either one extreme (simple and imperative, e.g. Arch) or the other (functional, NixOS).
- thepratt 9y ago
  I'm a big fan apart from how they version. Depending on when you install the version will point at a different commit hash. In our case, all of our Haskell builds failed on all but 1 machine (day apart in resolutions). How nixos handles environments meant our large package builds would kill the entire os, or underlying lib linking just failed - never figured out why, but it wasn't worth investing more time.
  - nextos 9y ago
    This is one of the usability problems they have. There are some simple solutions to this, but it should be more straightforward.
    - CMCDragonkai 9y ago
      Pinning is the answer to these usability problems.
- amasad 9y ago
  Excuse me if this question is too basic but how does a purely functional package manager work with a side-effectful package installation? In Python (or basically any other language package manager) you can run arbitrary scripts (post-install etc) and so this doesn't lend itself nicely to a reproducible, functional approach.
  - nextos 9y ago
    A quick and overly simplistic explanation is that all inputs (source code, package dependencies or post-install scripts) used to build a package are employed to compute a unique hash. Then the result of building a particular package is installed in /nix/store/hash-packagename. And this package links to other packages in the nix store using precise hashes. There is no dynamic linking. So the result is referentially transparent. A particular hash is guaranteed to correspond to the same package version, built in the same way and linked to the same dependencies. Furthermore, installing new package versions or modified versions of a package wont overwrite old ones, as hashes are different. The same concept applies to a whole system setup, which is identified by a hash computed using all options that configure the system plus all packages available in your environment.
smt88 9y ago
Do you use NixOS in production?
- MarcScott 9y ago
  I'm an educator, so my answer would have to be no, unless we're talking about producing educational material. People do though.
mamcx 9y ago
Where I can read about this? I wish to have a solution that replace dockers and globally installed stuff for me (I need to manage python, .net core, ios/android and several rdbms) on osx/linux. Is nixos the way?
Game_Ender 9y ago
What is the issue with PyQt5?
- MarcScott 9y ago
  PyQT5 is actually packaged, and I was just being lazy in my comment. It's actually pyqtchart and qscintilla that are the problems. They're not packaged for nix and won't install in a virtualenv with pip. Something to do with hardcoded paths for dependencies I think. I'm going to have a go at writing a nix files that build them from source, with the help of a NixOS expert, so we'll see how that goes.
  - CMCDragonkai 9y ago
    In the nixpkgs repository, sometimes you see certain packages requiring either patches to their source code or sed changes to config files because their build system was hardcoding paths that they shouldn't.
dorian-graph 9y ago
Would you mind doing a writeup? More and more people are have mentioned their success in using nix, but from what I've seen, there hasn't been a huge amount of accompanying docs.
rdtsc 9y ago
I've been following nixos for a while. I think there is a 2.0 version worked on, I am waiting for it to be release then I'll dive into deeper. On the surface from what I've seen it does all the things right and it is kind of what I expected Docker would before I used it.
CMCDragonkai 9y ago
My understanding is that you should be using shell.nix for your dev environment, and default.nix if you want to actually build the final "nix-package". I have a gist that talks about this along with python and other language environments: https://gist.github.com/CMCDragonkai/dcc1b538352624ea690d695ee1ff1528 https://gist.github.com/CMCDragonkai/dcc1b538352624ea690d695... However it's not finished, there are some things that still need work. However package/input isolation is not the only isolation you need sometimes (for example, network isolation, fs isolation...etc). When you do need this, Docker provides all these, but it's not compositional. There's a discussion on the Nix issues about this (potentially working towards a new nix-shell development environment can can compose different kinds of isolation): https://github.com/NixOS/nix/issues/903#issuecomment-364744764 https://github.com/NixOS/nix/issues/903#issuecomment-3647447...

nextos 9y ago

Nix is one of the most amazing things created lately. IMHO, it doesn't get the attention it deserves as it provides great solutions to really tough problems and it's ready for prime time. A purely functional package manager, distro, devops. And pretty soon, home directory management. Maintaining servers or doing aggressive changes becomes very easy. There's even a Darwin (macOS) implementation now, so you can manage most of your Mac functionally (with heavy usage of defaults under the hood). It's still lacking a bit on usability, as some things are not as intuitive as in a simple imperative distribution such as Arch or Alpine. Especially if you need to run some prepackaged software that assumes FHS and binds dynamically to some pre-existing dependencies. But to me, right now if you are a moderately advanced user I don't see a point in running distros that are stuck in the middle (imperative, complex, lots of defaults). It's either one extreme (simple and imperative, e.g. Arch) or the other (functional, NixOS).

thepratt 9y ago
I'm a big fan apart from how they version. Depending on when you install the version will point at a different commit hash. In our case, all of our Haskell builds failed on all but 1 machine (day apart in resolutions). How nixos handles environments meant our large package builds would kill the entire os, or underlying lib linking just failed - never figured out why, but it wasn't worth investing more time.
- nextos 9y ago
  This is one of the usability problems they have. There are some simple solutions to this, but it should be more straightforward.
  - CMCDragonkai 9y ago
    Pinning is the answer to these usability problems.
amasad 9y ago
Excuse me if this question is too basic but how does a purely functional package manager work with a side-effectful package installation? In Python (or basically any other language package manager) you can run arbitrary scripts (post-install etc) and so this doesn't lend itself nicely to a reproducible, functional approach.
- nextos 9y ago
  A quick and overly simplistic explanation is that all inputs (source code, package dependencies or post-install scripts) used to build a package are employed to compute a unique hash. Then the result of building a particular package is installed in /nix/store/hash-packagename. And this package links to other packages in the nix store using precise hashes. There is no dynamic linking. So the result is referentially transparent. A particular hash is guaranteed to correspond to the same package version, built in the same way and linked to the same dependencies. Furthermore, installing new package versions or modified versions of a package wont overwrite old ones, as hashes are different. The same concept applies to a whole system setup, which is identified by a hash computed using all options that configure the system plus all packages available in your environment.

smt88 9y ago

Do you use NixOS in production?

MarcScott 9y ago
I'm an educator, so my answer would have to be no, unless we're talking about producing educational material. People do though.

mamcx 9y ago

Where I can read about this? I wish to have a solution that replace dockers and globally installed stuff for me (I need to manage python, .net core, ios/android and several rdbms) on osx/linux. Is nixos the way?

Game_Ender 9y ago

What is the issue with PyQt5?

MarcScott 9y ago
PyQT5 is actually packaged, and I was just being lazy in my comment. It's actually pyqtchart and qscintilla that are the problems. They're not packaged for nix and won't install in a virtualenv with pip. Something to do with hardcoded paths for dependencies I think. I'm going to have a go at writing a nix files that build them from source, with the help of a NixOS expert, so we'll see how that goes.
- CMCDragonkai 9y ago
  In the nixpkgs repository, sometimes you see certain packages requiring either patches to their source code or sed changes to config files because their build system was hardcoding paths that they shouldn't.

dorian-graph 9y ago

Would you mind doing a writeup? More and more people are have mentioned their success in using nix, but from what I've seen, there hasn't been a huge amount of accompanying docs.

rdtsc 9y ago

I've been following nixos for a while. I think there is a 2.0 version worked on, I am waiting for it to be release then I'll dive into deeper. On the surface from what I've seen it does all the things right and it is kind of what I expected Docker would before I used it.

CMCDragonkai 9y ago

My understanding is that you should be using shell.nix for your dev environment, and default.nix if you want to actually build the final "nix-package". I have a gist that talks about this along with python and other language environments: https://gist.github.com/CMCDragonkai/dcc1b538352624ea690d695ee1ff1528 https://gist.github.com/CMCDragonkai/dcc1b538352624ea690d695... However it's not finished, there are some things that still need work. However package/input isolation is not the only isolation you need sometimes (for example, network isolation, fs isolation...etc). When you do need this, Docker provides all these, but it's not compositional. There's a discussion on the Nix issues about this (potentially working towards a new nix-shell development environment can can compose different kinds of isolation): https://github.com/NixOS/nix/issues/903#issuecomment-364744764 https://github.com/NixOS/nix/issues/903#issuecomment-3647447...