Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nix is the ultimate DevOps toolkit

tech.channable.com

Post reply on HN
Print view View original

181–190 of 243 posts

Re: Nix is the ultimate DevOps toolkit

#181

Post by jonringer117 »

throwaway894345 wrote: post #135
rkrzr wrote: post #127

Earlier quoted context omitted.

(author here) I agree that Nix not being statically typed is one of the biggest drawbacks of the language. Having it statically typed with a strong type system like Haskell's would help solve some of the readability issues that you mention. Types of course also serve as documentation, which is another often-mentioned weak point of the language. Finally, with static types we could also have much better editor support…

I think [Nickel][1] aims to add static types to Nix, but I don't know of any efforts to integrate Nickel into nixpkgs. [1]: https://github.com/tweag/nickel

It's still in development. But swapping a language is possible, as it's only needed for evaluation. Building the package (realization) just needs the derivation.

Re: Nix is the ultimate DevOps toolkit

#182

Post by raxi »

siraben wrote: post #53
georgyo wrote: post #40

Earlier quoted context omitted.

Having used nix for two years now for both work and personal purposes, I agree. Though I have also come to think nix is doing things in much better ways than AppImage, Docker, Snap, Flatpack, and others. I won't focus on the good parts, but focus on your comment. Nix has three things that I think are confusing and took me an embarrassing long time to grok, and I find other people confused by as well. 1. Where does th…

Regular Nix user here, I agree with your points regarding the language's peculiarities, and adding on a few points: > 1. Where does the semicolon go? Reading code makes it feel arbitrary, but really the only time a semicolon is used is to terminate an assignment (=). If there are no equal signs, then you don't need any semicolons. The semicolon is also required when using with expressions (i.e. augments the environme…

`with` should be considered harmful.

Well, you recognized the gotcha, but there are people who don't, they inserted a bug into nixpkgs, then someone else fixed it not realizing its genesis. There is a lot of spaghetti code in nixpkgs caused by misunderstanding of `with`

Re: Nix is the ultimate DevOps toolkit

#183

Post by hinkley »

Wazzymandias wrote: post #176

Nothing should be labeled as the ultimate devops toolkit when its documentation is as atrocious as nix People can commend it as much as they want, but the steep learning curve is largely self inflicted because of their resistance to writing clean, comprehensive, up to date docs It has also led to the community being filled with a lot of arrogance and pretentiousness I wouldn't run nix in production because of the lac…

> It has also led to the community being filled with a lot of arrogance and pretentiousness

I would conjecture that you have cause and effect reversed.

When people think they're doing you a favor, the ego protects itself from hearing how their help is not actually that helpful. See aid to Africa in the 80's and 90's for example.

Re: Nix is the ultimate DevOps toolkit

#184

Post by jonringer117 »

mdoms wrote: post #164
microtonal wrote: post #137

Earlier quoted context omitted.

If you try to make a Go package, for example, you end up having to provide a hash. To generate the hash `vendorSha256`, you have to run `nix-prefetch`, but that program is broken on MacOS. You can also stub the hash (e.g. with lib.fakeSha256 ). nix-build will fail with a hash mismatch and tell you the correct hash. I mentioned elsewhere that I spent a weekend working with the Nix discord to try to install VS Code wit…

> You can also stub the hash (e.g. with lib.fakeSha256). nix-build will fail with a hash mismatch and tell you the correct hash. Are you kidding me?

It's content addressable. If you use the old hash, it will just use the "old" contents happily (unless they don't exist). So you have to alter it slightly to get a "cache miss" to see what should have been produced.

This can be address by adding the version to the dependencies store path. This has been done for rust builds, not sure about go.

Re: Nix is the ultimate DevOps toolkit

#185

Post by raxi »

kaba0 wrote: post #61
root_axis wrote: post #42

I love nix as a concept, but in my experience it isn't practical on systems without a ton of memory. I regularly get build errors due to oom errors.

That’s strange, are you actually compiling packages or the evaluation itself ooms? Because if the former, you may help it by limiting concurrent builds.

Evaluating/compiling packages is not greedy.

Memory is eaten by lazy evaluation of NixOS modules.

It can be optimized, but it is not a low-hanging fruit. It is still waiting for its hero. I'd compare it with creating the V8 for JavaScript.

Re: Nix is the ultimate DevOps toolkit

#186

Post by alrs »

nonameiguess wrote: post #108
alrs wrote: post #11

The merges-straight-to-master give me the willies. https://botsin.space/@complainingaboutmastercommits

It's not fair at all that this is presently the most downvoted comment. Like it or not, this is a real concern, even if the count is illusory. It's not just about humans seeing this, but automated risk assessment tools use this kind of thing as a metric and showing a bunch of commits straight to master can prevent enterprise and government adoption due to policy. Maybe that doesn't matter for you, but innovators igno…

My feelings aren't hurt, I've collected a datapoint on the prevalence of kinda-naive super-fans in the nix community for the low price of three Internet points.

Re: Nix is the ultimate DevOps toolkit

#187

Post by lfam »

bfrog wrote: post #139

I use nix today for ci/cd to build a large C++ project for a variety of architectures using cross-compiles. While it could be done with adhoc scripts, some cross compiler tool environment tool + conan, or something else, I effectively wrote my nix expression once to package up everything, and simply changed the target arch and libc and got what I wanted. It's not perfect, but it works, its fast, and its better than t…

Hey, we're glad to hear you're interested in Guix :)

I just wanted to say that Guix doesn't hate systemd, or think of itself as an anti-systemd project or anything like that.

Systemd was not chosen because GNU already had a (quite simplistic) init system written in Guile Scheme, and we want to use Guile for the entire system.

Eventually, our goal is to offer a fully integrated interface for managing the system, just like systemd. We are not there yet :)

Re: Nix is the ultimate DevOps toolkit

#188

Post by TobyBrull »

Not a Nix user, but I spent some time trying to understand it. One thing that I wish I would have understood earlier is that "Nix Pills" is a decent, bottom-up Nix tutorial and probably a good place to start. Initially I thought "Nix Pills" was just a collection of recipes ("Nix By Example"), but it is not.

Re: Nix is the ultimate DevOps toolkit

#189

Post by otabdeveloper4 »

jpe90 wrote: post #138
otabdeveloper4 wrote: post #126

Earlier quoted context omitted.

At the moment the happy path for Nix is using it in the same space that Docker is used now - for providing reproducible dev/prod environments for server backends. (And in fact Docker and Nix complement and play nice with each other.) You could theoretically use Nix for managing user apps too, but that's a niche use case and (as you found out) not in a working state.

So for the happy path, are you declaring the entire development toolchain on a project by project basis? Any chance you have some recommended resources that show the way you're using it? I was hoping to use it for Haskell but I'd love to see a guide targeted to new users that shows what you're describing.

Yeah, each project has its own default.nix that might look something like this:

    {
      pkgs ? import (fetchTarball "https://github.com/NixOS/nixpkgs/archive/cd63096.tar.gz") { }
    } :
    with pkgs;
    let
      mypackage = callPackage ./mypackage.nix { stdenv = stdenv; python = python3; };
    in
    dockerTools.buildImage {
      contents = [ mypackage ];
    }
You then write a package definition in mypackage.nix, following the template of packaging things in nixpkgs.

(Dev environments work in a similar fashion except with mkShell instead of dockerTools.buildImage.)

I haven't used Nix flakes but I think it develops this simple idea further.

Re: Nix is the ultimate DevOps toolkit

#190

Post by chriswarbo »

jeofken wrote: post #163
chriswarbo wrote: post #104

Earlier quoted context omitted.

> Bonus 4. In nix it is really easy to build single language applications. However if you need to mix two, finding good docs or examples is really hard. IE, if you want to build the javascript front end of your web app as well as the python backend. These combinations need at least two derivations, and how to make it happen is bespoke every time. For anything that doesn't fit a common nixpkgs function (like `buildPyt…

Thanks for the example - I’ve been looking for how to make mix packaging easy. How do you add files to this build? For example, if I have this program.rb that depends on ruby: puts “Hello World” And then you add a file called package.nix let pkgs = import {}; in pkgs.runCommand "my-app" { buildInputs = [pkgs.ruby]; } '' pwd && ls; ruby ./program.rb '' How do you get your files in there - like “ADD” in a Dockerfile?

You can splice file paths directly into the script, like this:

    let pkgs = import  {}; in
    pkgs.runCommand "my-app"
      {
        buildInputs = [pkgs.ruby];
      }
      ''
        pwd && ls
        ruby ${./program.rb}
      ''
Or you could add it as an env var:

    let pkgs = import  {}; in
    pkgs.runCommand "my-app"
      {
        buildInputs = [pkgs.ruby];
        program = ./program.rb;
      }
      ''
        pwd && ls;
        ruby "$program"
      ''
Post reply on HN