12 ms·

as platform engineer, i want to like nix. but it's not easy for everyone else. and the dx is still pretty bad IMO. for example, i prefer devbox DX just becaus

as platform engineer, i want to like nix. but it's not easy for everyone else. and the dx is still pretty bad IMO. for example, i prefer devbox DX just because i can add pkg like this `devbox add python@3.11`. also, looking at 120 lines flake.nix. it's not exactly "easier" https://github.com/Xe/douglas-adams-quotes/blob/main/flake.nix https://github.com/Xe/douglas-adams-quotes/blob/main/flake.n...

klntsky 3y ago
These 120 lines do quite a lot more, don't they?
Cyph0n 3y ago
That's kind of an unfair comparison. The flake you linked: 1. Defines a Go binary (i.e., how to build it) 2. Defines a Docker image that uses said Go binary as an entry point 3. Defines a NixOS module that creates a systemd service that runs the Go binary (only relevant on NixOS) 4. Defines a NixOS test for the module that ensures that the NixOS module actually creates a systemd service that runs the Go binary as expected. The NixOS test framework is actually quite impressive - tests run in a QEMU VM that also runs NixOS :) Note that only (1) and (2) are relevant to the linked article (+ some of the surrounding boilerplate).
- hamandcheese 3y ago
  I agree that it's not a fair comparison, but I will add that this is a big barrier to newcomers. Everyone experienced with nix builds their own ivory tower of a nix flake (myself included), so it's hard to find actually good examples of how to do basic things without wading through a bunch of other bullshit.
  - Cyph0n 3y ago
    I'm a beginner myself and have been trying my best to keep things simple. But I do agree that the complexity creep is quite tempting with Nix. Not sure why though..
    - hamandcheese 3y ago
      I think nix has a fair amount of gravity - once you've started, assuming like it, you will quickly want to use it for everything. I don't think most people's flakes are more complex than the alternative (which would be, I don't know, a bunch of different script, maybe some ansible playbooks?) but it is a bit daunting when all that complexity is wrangled into a single abstraction.
  - rapnie 3y ago
    Newcomer here. Could anyone tell if std [0] is a good way to bring more sanity into flake design, esp. in avoiding ivory towery custom approaches? Using devenv.sh is another option, but I liked emphasis on creating a common mental picture of the architecture and focus on SLDC that std provides. [0] https://std.divnix.com https://std.divnix.com
    - hamandcheese 3y ago
      I haven't used std, but I would like to point you at what I think is the ideal way to organize a lot of nix: readTree from the virus lounge[0]. It doesn't add kitschy terms like "Cell" and "growOn", it's just a way to standardize attribute names according to where things live in the filesystem. So in their repo, /foo/bar/baz.nix has the attribute path depot.foo.bar.baz I will say that to understand how it works you need to have a solid grasp of the nix language. But once established I think it's a pattern that noobs could learn in a very quick and superficial way. [0]: https://cs.tvl.fyi/depot/-/blob/nix/readTree/README.md https://cs.tvl.fyi/depot/-/blob/nix/readTree/README.md
      - rapnie 3y ago
        Thank you! I already bumped into the virus lounge, with their TVIX project [0] that I found quite interesting. [0] https://code.tvl.fyi/about/tvix https://code.tvl.fyi/about/tvix
      - Cu3PO42 3y ago
        I really like this. In fact, I have an extremely similar home-grown abstraction. I might look into standardizing on this.
    - OJFord 3y ago
      What on Earth is the background reading supposed to be for https://std.divnix.com/explain/why-std.html https://std.divnix.com/explain/why-std.html, a supposedly motivating page for newcomers? I've even used Nix a little bit (though early days, before flakes) and it makes absolutely no sense to me.
  - MadnessASAP 3y ago
    I thought I was weird for my bespoke ivory tower monorepo flake.nix, glad to hear I'm not the only one. It has been a tremendous help in managing my homelab.
- mkleczek 3y ago
  Does Nix make it difficult to properly modularise nix files (flakes or not)? Because it certainly looks like the things you listed are separate/orthogonal and should be in separate modules/files. Having many years of Java experience this is the reason why I stick to Maven (not moving to Gradle) - it is opinionated and strongly encourages fine grained modularisation.
  - yjftsjthsd-h 3y ago
    > Because it certainly looks like the things you listed are separate/orthogonal and should be in separate modules/files. Nix absolutely allows that, to the point where I'm surprised that the linked example doesn't separate them. Most of my flakes have a flake.nix that's just a thin wrapper around a block that looks like devShell = import ./shell.nix { inherit pkgs; }; defaultPackage = import ./default.nix { inherit pkgs; }; ...
    - yencabulator 3y ago
      The thing that makes that miserable is all the inputs need to be declared in the top-level flake. They really should make using flakes in subdirectories of the same git repo painless. (Right now they're treated as if they were remote, and you need to "upgrade" them after every change; unusable.)
    - mkleczek 3y ago
      And what's the story with generic libraries that can later be used in your nix files to produce desired output? I am aware of flake-parts that are supposed to offer that but the ecosystem of flake-parts is on the smaller side of things...
      - lkjdsklf 3y ago
        Maybe I'm not understanding your question, but this is what the inputs of flakes are for. You can pull in arbitrary code from pretty much anywhere as an input
viraptor 3y ago
Those 120 lines are not exactly representative. For example if I was writing this for a single service, I wouldn't bother making a new module and would inline it instead. Then, you've got many lines which would map 1:1 to an inlined systemd service description, so you're not getting rid of those whatever the system you choose. There's also a fancy way to declare multiple systems with an override. This example is a "let's do a trivial thing the way you'd do a big serious thing". If you wanted to treat it as a one-off, I'm sure you could cut it down to 40 lines or so.
- whydoineedthis 3y ago
  So I can write a Dockerfile using 17 verbs (13, actually), and it's understandable language to a 4th grader... or I can write 120 lines of complete abstract nix code that means nothing to someone doing software for 20 years. Hrmmmm...this is such a TOUGH decision.
  - xena 3y ago
    I've used this app for like four different talks over the years, I could clean it up, but then I break code samples in my talks.
  - m463 3y ago
    I would like to mention one pet peeve of mine wrt docker... cramming everything into one RUN line to save space in a layer. I really wish instead of: RUN foo && \ bar && \ bletch You could do: LAYER RUN foo RUN bar RUN bletch LAYER or something similar. maybe even during development you could do: docker build --ignore-layer . then at the end: docker build .
    - viraptor 3y ago
      Cramming things into one layer can save gigabytes in size. Even if it saves a 100MB, it adds up between multiple CI runs and in deployment latencies. Docker should address it one day, but until then, we just have to do it in real world scenarios.
zer00eyz 3y ago
its 120 lines of code to deal with a binary and its systemd setup. That binary + config file are effectively as close as we're going to get to a "flat pack" on linux. Im not sure what is the forest and where are the trees but this example shows exactly what we have lost sight of.

klntsky 3y ago

These 120 lines do quite a lot more, don't they?

Cyph0n 3y ago

That's kind of an unfair comparison. The flake you linked: 1. Defines a Go binary (i.e., how to build it) 2. Defines a Docker image that uses said Go binary as an entry point 3. Defines a NixOS module that creates a systemd service that runs the Go binary (only relevant on NixOS) 4. Defines a NixOS test for the module that ensures that the NixOS module actually creates a systemd service that runs the Go binary as expected. The NixOS test framework is actually quite impressive - tests run in a QEMU VM that also runs NixOS :) Note that only (1) and (2) are relevant to the linked article (+ some of the surrounding boilerplate).

hamandcheese 3y ago
I agree that it's not a fair comparison, but I will add that this is a big barrier to newcomers. Everyone experienced with nix builds their own ivory tower of a nix flake (myself included), so it's hard to find actually good examples of how to do basic things without wading through a bunch of other bullshit.
- Cyph0n 3y ago
  I'm a beginner myself and have been trying my best to keep things simple. But I do agree that the complexity creep is quite tempting with Nix. Not sure why though..
  - hamandcheese 3y ago
    I think nix has a fair amount of gravity - once you've started, assuming like it, you will quickly want to use it for everything. I don't think most people's flakes are more complex than the alternative (which would be, I don't know, a bunch of different script, maybe some ansible playbooks?) but it is a bit daunting when all that complexity is wrangled into a single abstraction.
- rapnie 3y ago
  Newcomer here. Could anyone tell if std [0] is a good way to bring more sanity into flake design, esp. in avoiding ivory towery custom approaches? Using devenv.sh is another option, but I liked emphasis on creating a common mental picture of the architecture and focus on SLDC that std provides. [0] https://std.divnix.com https://std.divnix.com
  - hamandcheese 3y ago
    I haven't used std, but I would like to point you at what I think is the ideal way to organize a lot of nix: readTree from the virus lounge[0]. It doesn't add kitschy terms like "Cell" and "growOn", it's just a way to standardize attribute names according to where things live in the filesystem. So in their repo, /foo/bar/baz.nix has the attribute path depot.foo.bar.baz I will say that to understand how it works you need to have a solid grasp of the nix language. But once established I think it's a pattern that noobs could learn in a very quick and superficial way. [0]: https://cs.tvl.fyi/depot/-/blob/nix/readTree/README.md https://cs.tvl.fyi/depot/-/blob/nix/readTree/README.md
    - rapnie 3y ago
      Thank you! I already bumped into the virus lounge, with their TVIX project [0] that I found quite interesting. [0] https://code.tvl.fyi/about/tvix https://code.tvl.fyi/about/tvix
    - Cu3PO42 3y ago
      I really like this. In fact, I have an extremely similar home-grown abstraction. I might look into standardizing on this.
  - OJFord 3y ago
    What on Earth is the background reading supposed to be for https://std.divnix.com/explain/why-std.html https://std.divnix.com/explain/why-std.html, a supposedly motivating page for newcomers? I've even used Nix a little bit (though early days, before flakes) and it makes absolutely no sense to me.
- MadnessASAP 3y ago
  I thought I was weird for my bespoke ivory tower monorepo flake.nix, glad to hear I'm not the only one. It has been a tremendous help in managing my homelab.
mkleczek 3y ago
Does Nix make it difficult to properly modularise nix files (flakes or not)? Because it certainly looks like the things you listed are separate/orthogonal and should be in separate modules/files. Having many years of Java experience this is the reason why I stick to Maven (not moving to Gradle) - it is opinionated and strongly encourages fine grained modularisation.
- yjftsjthsd-h 3y ago
  > Because it certainly looks like the things you listed are separate/orthogonal and should be in separate modules/files. Nix absolutely allows that, to the point where I'm surprised that the linked example doesn't separate them. Most of my flakes have a flake.nix that's just a thin wrapper around a block that looks like devShell = import ./shell.nix { inherit pkgs; }; defaultPackage = import ./default.nix { inherit pkgs; }; ...
  - yencabulator 3y ago
    The thing that makes that miserable is all the inputs need to be declared in the top-level flake. They really should make using flakes in subdirectories of the same git repo painless. (Right now they're treated as if they were remote, and you need to "upgrade" them after every change; unusable.)
  - mkleczek 3y ago
    And what's the story with generic libraries that can later be used in your nix files to produce desired output? I am aware of flake-parts that are supposed to offer that but the ecosystem of flake-parts is on the smaller side of things...
    - lkjdsklf 3y ago
      Maybe I'm not understanding your question, but this is what the inputs of flakes are for. You can pull in arbitrary code from pretty much anywhere as an input

viraptor 3y ago

Those 120 lines are not exactly representative. For example if I was writing this for a single service, I wouldn't bother making a new module and would inline it instead. Then, you've got many lines which would map 1:1 to an inlined systemd service description, so you're not getting rid of those whatever the system you choose. There's also a fancy way to declare multiple systems with an override. This example is a "let's do a trivial thing the way you'd do a big serious thing". If you wanted to treat it as a one-off, I'm sure you could cut it down to 40 lines or so.

whydoineedthis 3y ago
So I can write a Dockerfile using 17 verbs (13, actually), and it's understandable language to a 4th grader... or I can write 120 lines of complete abstract nix code that means nothing to someone doing software for 20 years. Hrmmmm...this is such a TOUGH decision.
- xena 3y ago
  I've used this app for like four different talks over the years, I could clean it up, but then I break code samples in my talks.
- m463 3y ago
  I would like to mention one pet peeve of mine wrt docker... cramming everything into one RUN line to save space in a layer. I really wish instead of: RUN foo && \ bar && \ bletch You could do: LAYER RUN foo RUN bar RUN bletch LAYER or something similar. maybe even during development you could do: docker build --ignore-layer . then at the end: docker build .
  - viraptor 3y ago
    Cramming things into one layer can save gigabytes in size. Even if it saves a 100MB, it adds up between multiple CI runs and in deployment latencies. Docker should address it one day, but until then, we just have to do it in real world scenarios.

zer00eyz 3y ago

its 120 lines of code to deal with a binary and its systemd setup. That binary + config file are effectively as close as we're going to get to a "flat pack" on linux. Im not sure what is the forest and where are the trees but this example shows exactly what we have lost sight of.