4 ms·

In view of some replies downthread: yes, application-level management is entirely possible with Nix(OS). Currently, this works best for Haskell, for which ther

In view of some replies downthread: yes, application-level management is entirely possible with Nix(OS). Currently, this works best for Haskell, for which there is a sizeable amount (relatively speaking) of Nix tooling available. This is largely because a lot of Nix(OS) users also use Haskell, perhaps because lend themselves to very similar modes of "declarative" thinking. This is a thorough, excellent guide on how to develop Haskell projects with Nix, including managing non-Haskell dependencies (zlib, SDL, ncurses, and so on): https://github.com/Gabriel439/haskell-nix/ https://github.com/Gabriel439/haskell-nix/ I only started using NixOS about a month ago, and it's fantastic. The best part is that binary caches are available for almost everything, so the hitherto-painful step where one compiles Haskell dependencies locally has been completely eliminated. The best way I can describe how I work now is "Python virtualenvs, but for everything at once and just so much better". PS. Gabriel Gonzalez is, in general, someone who makes great documenation. Check out the tutorial for his stream-processing library Pipes: the ASCII art alone is awesome :) https://hackage.haskell.org/package/pipes-4.3.4/docs/Pipes-Tutorial.html https://hackage.haskell.org/package/pipes-4.3.4/docs/Pipes-T...

arianvanp 9y ago
Gabriel also has a great blog http://www.haskellforall.com/ http://www.haskellforall.com/ Basically the kind of person I would love to buy a beer any time because he does so much great work. on topic: The binary caches are great. For work I'm currently evaluating https://github.com/typeable/stackage2nix https://github.com/typeable/stackage2nix and https://github.com/input-output-hk/stack2nix https://github.com/input-output-hk/stack2nix to generate nix expressions from our haskell stack projects. And then push the build artifacts to a shared cache. Such that nobody has to ever compile a dependency twice. Because nothing sucks more than starting your day watching the compiler churn away at compiling after version bumps, to then also see a collegue go to the same pain all over again.
Ixiaus 9y ago
We use NixOS in production in our product, for our cloud services, and for some development environments. We build everything with nix from sbt projects, go projects, haskell projects, purescript projects, docker images, and npm projects. It's an incredible tool. NixOps is also a good tool but there are a lot of issues with it we haven't had time to contribute fixes for. We also wanted it to be lighter weight and to decouple system specification from system deployment. So I wrote a tool that handles performing the same system deployment operations that NixOps does for you and you can simply pipe the nix path result from nix-build to it. We use terraform to specify and manage the cloud resources.
- tryckbarpingvin 9y ago
  Are you able to share your tool?
  - Ixiaus 9y ago
    We will definitely be publishing it. Time is very short and the backlog of projects to publish is growing though so it might take time to polish and write a blogpost and tutorial. I work for Awake Security so keep an eye out on the company's GitHub org as we've been publicly releasing a lot of projects even though they aren't completely polished or announced yet. I'll see if I can do this for our deploy tool soon.
    - iElectric2 9y ago
      Nice, I'd love to see it released.
nextos 9y ago
I love Nix concepts and all it's subprojects (NixOS, NixOps, Hydra, Disnix). However, i've found NixPkgs to be a bit messy. It's too big, targets too many platforms and it's too disorganised. But to be completely fair, I think it's getting a lot of good refactorings lately.
- solatic 9y ago
  Yeah it's basically just growing pains. For large enterprise use, Nix is going to need to mature to a point where it's possible for enterprises to host a Nixpkgs cache locally, using a binary repository manager like Artifactory or Nexus, both for sheer cost (to save on bandwidth of thousands of servers downloading updates from the Internet) as well as risk reduction (in case the public binary caches are unavailable at critical moments). If this is doable today, it's not really documented. I'm sure the project will get there... eventually.
  - nextos 9y ago
    I found Guix a lot more organised. Most package code is very simple, and the toolchain is also quite elegant. Hopefully the latter will be addressed by the new nix interface.
    - solatic 9y ago
      Is GuixSD really usable in production? Its focus on using a Linux-libre kernel instead of mainline is worrisome regarding real-world hardware support.
      - nextos 9y ago
        Switching to mainline is almost trivial, just override plain linux-libre kernel and redefine the source. GuixSD is getting production-ready IMHO. See for example Guix getting adopted by some HPCs: https://guix-hpc.bordeaux.inria.fr/ https://guix-hpc.bordeaux.inria.fr/
  - catern 9y ago

arianvanp 9y ago

Gabriel also has a great blog http://www.haskellforall.com/ http://www.haskellforall.com/ Basically the kind of person I would love to buy a beer any time because he does so much great work. on topic: The binary caches are great. For work I'm currently evaluating https://github.com/typeable/stackage2nix https://github.com/typeable/stackage2nix and https://github.com/input-output-hk/stack2nix https://github.com/input-output-hk/stack2nix to generate nix expressions from our haskell stack projects. And then push the build artifacts to a shared cache. Such that nobody has to ever compile a dependency twice. Because nothing sucks more than starting your day watching the compiler churn away at compiling after version bumps, to then also see a collegue go to the same pain all over again.

Ixiaus 9y ago

We use NixOS in production in our product, for our cloud services, and for some development environments. We build everything with nix from sbt projects, go projects, haskell projects, purescript projects, docker images, and npm projects. It's an incredible tool. NixOps is also a good tool but there are a lot of issues with it we haven't had time to contribute fixes for. We also wanted it to be lighter weight and to decouple system specification from system deployment. So I wrote a tool that handles performing the same system deployment operations that NixOps does for you and you can simply pipe the nix path result from nix-build to it. We use terraform to specify and manage the cloud resources.

tryckbarpingvin 9y ago
Are you able to share your tool?
- Ixiaus 9y ago
  We will definitely be publishing it. Time is very short and the backlog of projects to publish is growing though so it might take time to polish and write a blogpost and tutorial. I work for Awake Security so keep an eye out on the company's GitHub org as we've been publicly releasing a lot of projects even though they aren't completely polished or announced yet. I'll see if I can do this for our deploy tool soon.
  - iElectric2 9y ago
    Nice, I'd love to see it released.

nextos 9y ago

I love Nix concepts and all it's subprojects (NixOS, NixOps, Hydra, Disnix). However, i've found NixPkgs to be a bit messy. It's too big, targets too many platforms and it's too disorganised. But to be completely fair, I think it's getting a lot of good refactorings lately.

solatic 9y ago
Yeah it's basically just growing pains. For large enterprise use, Nix is going to need to mature to a point where it's possible for enterprises to host a Nixpkgs cache locally, using a binary repository manager like Artifactory or Nexus, both for sheer cost (to save on bandwidth of thousands of servers downloading updates from the Internet) as well as risk reduction (in case the public binary caches are unavailable at critical moments). If this is doable today, it's not really documented. I'm sure the project will get there... eventually.
- nextos 9y ago
  I found Guix a lot more organised. Most package code is very simple, and the toolchain is also quite elegant. Hopefully the latter will be addressed by the new nix interface.
  - solatic 9y ago
    Is GuixSD really usable in production? Its focus on using a Linux-libre kernel instead of mainline is worrisome regarding real-world hardware support.
    - nextos 9y ago
      Switching to mainline is almost trivial, just override plain linux-libre kernel and redefine the source. GuixSD is getting production-ready IMHO. See for example Guix getting adopted by some HPCs: https://guix-hpc.bordeaux.inria.fr/ https://guix-hpc.bordeaux.inria.fr/
- catern 9y ago