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

91–100 of 243 posts

Re: Nix is the ultimate DevOps toolkit

#91

Post by chriswarbo »

tnzm wrote: post #71
chaorace wrote: post #66

Earlier quoted context omitted.

Agreed, but perhaps they should officially adopt home-manager then? It felt strange to me that the best way to be using nix was a separate community project.

I don't use nix-env or home-manager. On my NixOS workstation everything (outside of nix-shells) is installed via environment.systemPackages. And I do wish there was an easy way to add stuff to install packages without rebuilding the whole system - I guess that's what nix-env is for but if I went with that I would the "single editable config file that you can put in VCS" aspect. I think nix-env uses profiles, which ar…

You can define a package that contains a bunch of other things, e.g. I use packages like 'devCli', 'netGui', etc. (I actually put these in my systemPackages on NixOS and nix-darwin, but they would also work with nix-env)

http://chriswarbo.net/git/nix-config/git/branches/master/ove...

Re: Nix is the ultimate DevOps toolkit

#92

Post by mikepurvis »

duijf wrote: post #68
mikepurvis wrote: post #41

A lot of this sounds familiar to me— I maintain a hodgepodge build tool/pipeline at my org whose current output is a monolithic mega-deb file which is becoming unwieldy on several fronts (storage, transfer, compression time). I'm really interested in the nix philosophy of separate paths and versioning by hash rather than number, but unfortunately my needs are quite specific, and not having actual experienced nix expe…

> What is the story in nix for packaging untagged branches of software Most Nix packages define their sources using `src`. You can pass in whatever you want. E.g. fetch a tarball from GitHub with `fetchUrl`, fetch from a git repository, or point to a local directory. > or reasoning about "snapshots" where pools of unreleased repos/packages are able to be treated as a single versionable unit? This is basically what th…

Thanks for the response!

> This is difficult to answer without knowing more details.

The situation specifically is the ROS ecosystem, where metadata is managed in these package.xml files:

https://github.com/ros2/rclcpp/blob/master/rclcpp/package.xm...

The federated nature of the ecosystem has led to a culture where it's very normal to be building dozens of these at once, in the same workspace together, often from multiple repos (the repo above has four in it). So there are several build tools which automate the work of examining a source workspace and building all the packages within it in the correct topological order, in parallel, while respecting build_depend tags. The newest of these tools (colcon) has actually made the package.xml optional in many cases, as it can examine CMakelists, setup.py, BUILD, etc, and discover for itself what the dependencies are.

Your "distribution" of ROS is formed by listing all the packages and repos in this big file, for which there is other tooling to manage pulling dependency sources, whatever: https://github.com/ros/rosdistro/blob/master/foxy/distributi...

Anyway, so the existing ROS/nix efforts (1) seem to basically consume all of this package/distribution metadata at once and generate a giant parallel structure of nix definitions (eg https://github.com/lopsided98/nix-ros-overlay/blob/master/di...), which I fear would be completely opaque to my users. And any system which required a flag day where everyone leaves behind these existing workflows would be an immediate non-starter.

I think the ideal scenario (and what it would look like if I built this myself based on debs) would be that you could source the "base" workspace as usual (enter the nix-shell?), and check out source, build groups of packages as usual with colcon, but there'd be an extra plugin/verb/flag for it, which would make it build each package as a nix package instead of into the usual installspace. The verb would generate the nix definitions on the fly, and probably handle the invocation and build-parallelism side of it as well.

[1]: https://github.com/acowley/ros2nix, https://github.com/lopsided98/nix-ros-overlay

Re: Nix is the ultimate DevOps toolkit

#93

Post by trulyrandom »

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.

Yeah, it's clear that Nix has not been optimized to run on resource constrained devices. I run NixOS on a Raspberry Pi with 1GB of RAM and had to enable swap to prevent Nix from running into OOM situations. Any system with more memory than 1GB is usually fine in my experience though.

Re: Nix is the ultimate DevOps toolkit

#94

Post by microtonal »

georgyo wrote: post #62
q3k wrote: post #47

Earlier quoted context omitted.

> What is the story in nix for packaging untagged branches of software, or reasoning about "snapshots" where pools of unreleased repos/packages are able to be treated as a single versionable unit? A Nix derivation (a.k.a. 'packaging unit') can be built from sources either fetched remotely, or from a local directory, or a combination of both; plus any other derivation that it depends on. Any version semantics come fro…

> Not aware of anything out of the box. Nix builds only run on Nix (as they all need dependencies from /nix/store/..., and that is populated by Nix itself), so don't expect to easily run them on Debian without some disgusting home-rolled hacks. You could technically consume binary .debs from Debian within nix derivations (see previous point), but that's ugly. This is not true and no hacks are needed. Since nix only d…

This is not true and no hacks are needed. Since nix only depends on /nix it can be used in combination with ANY linux OS.

Just so that noone runs into issues. This is not completely true. E.g. you cannot use Nix on Fedora Silverblue, because it also uses an immutable filesystem and you cannot make top-level directories like /nix without ugly hacks.

Also, multi-user Nix does not work on most distributions that enforce an SELinux policy (e.g. Fedora/CentOS/RHEL). Incorrect SELinux contexts get set on store files/directories. Single-user Nix typically works fine though.

(These issues can be worked around with rootless Nix, but that is much more high-friction than a globally installed Nix.)

Re: Nix is the ultimate DevOps toolkit

#95

Post by oblio »

domenkozar wrote: post #64
jpe90 wrote: post #51

I tried Nix a few days ago. I set it up on an existing Arch install. I installed a couple of packages with "nix-env -i [package] and then tried to update them with "nix-env -u" as instructed in the official documentation: https://nixos.org/manual/nix/stable/#ch-basic-package-mgmt This ended up breaking the entire install. After a few hours of troubleshooting I found that the reason it broke was that it updated itself…

That's another problem of documentation. The correct way is to search for packages as the following: https://nix.dev/tutorials/ad-hoc-developer-environments.html... And then install via: nix-env -iA attribute-name New Nix CLI as part of next release fixes that, but it's not out yet.

Now, don't get me wrong, I don't have a horse in this race.

But as a complete outsider, this doesn't fill me with confidence. If Wikipedia is to be believed, NixOS was launched in 2003, so 18 (!) years ago, I assume that's when Nix was created.

The issue mentioned seems quite basic and you're replying that it will be fixed in a new Nix CLI.

This seems like a basic QA fail, I wouldn't want anything like this within 100 km of any production environment I'm working on.

I imagine Nix is underfunded, but few projects come back from stuff like this. If they can't get their stuff together in almost 2 decades, who will ever trust them that they ever will?

Re: Nix is the ultimate DevOps toolkit

#97

Post by arianvanp »

candiddevmike wrote: post #17

The gotcha I have with Nix is it's too much abstraction. I have to look at the upstream documentation, then try and map it to Nix's config syntax, then hope everything works. Also, regarding DevOps, the tooling around Nix makes it a little brittle for anything event based--rapidly changing configurations on the fly due to network conditions (Consul, Ansible, etc). This is where configuration management is heading, an…

Terraform seems to have the same 'problem' as nix in that regard; but Hashicorp came up with a solution to that recently:

https://www.hashicorp.com/blog/announcing-consul-terraform-s...

I wonder if something like that for nix would help you.

E.g. have the nix config in consul; and have the local daemon `watch` the consul config (And services) and build and acitvate the nix thing every time the consul config changes.

Could maybe even do automatic rollbacks based on consul health checks.

I think it could work pretty well!

Re: Nix is the ultimate DevOps toolkit

#98

Post by chriswarbo »

georgyo wrote: post #40
supermatt wrote: post #9

I spend a few hours looking at nix about a year ago and found it impenetrable. I simply do not grok the syntax or what the functions do. I tried searching for the functions shown in the examples on the website to no avail. I searched packages, options, and even resorted to ctrl-f while clicking through the site "documentation"... It sounds awesome, but its in dire need of some better documentation if it wants to be a…

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…

> the only time a semicolon is used is to terminate an assignment (=)

I find it easier to think of "attribute sets" like `{ foo = bar; }` more like a JSON objects (e.g. `{ "foo": bar }`) rather than "assignment".

Nix does have a `let` syntax, which probably looks more like assignment, but I've never used it in the 7 years I've been using Nix. I find `with myAttrs; myExpr` to be far better (except for the WontFix issue that `with` doesn't shadow function arguments).

Off the top of my head, the following expressions also require `;`:

    with myAttrs; myBody
    assert myCondition; myBody
The way I remember this is that every Nix expression returns a value; yet `with myAttrs` doesn't have a value, and neither does `assert myCondition`. Hence they have a separate return value "stuck on" via the `;`

Re: Nix is the ultimate DevOps toolkit

#100

Post by oblio »

ivanbakel wrote: post #38
supermatt wrote: post #9

I spend a few hours looking at nix about a year ago and found it impenetrable. I simply do not grok the syntax or what the functions do. I tried searching for the functions shown in the examples on the website to no avail. I searched packages, options, and even resorted to ctrl-f while clicking through the site "documentation"... It sounds awesome, but its in dire need of some better documentation if it wants to be a…

I am of a similar opinion, but I think it's largely due to my typical use case. If you use Nix in a "drive-by" kind of way, it's very hard to make any inroads into the language. The documentation and tutorials are not really intended for a casual user - it is expected you will sit down with the Nix site like a good book, and go at it from start to finish. If (like me) you instead touch Nix little and often, doing sma…

> If you use Nix in a "drive-by" kind of way, it's very hard to make any inroads into the language. The documentation and tutorials are not really intended for a casual user - it is expected you will sit down with the Nix site like a good book, and go at it from start to finish. If (like me) you instead touch Nix little and often, doing small invocations or on-the-fly editing, the docs are much less useful.

This is super serious, major, I hope the devs are paying attention.

Most users of anything are drive-by, rather casual users. Think of any big tech out there: they became popular precisely because they were easy to get started (at least back when they were launched/became popular): C, Unix, Bash, Perl, PHP, MySQL, Javascript, Java, Ruby, Go, etc. Almost everything that's big was usable by people don't read an entire book before they can make "Hello world".

Post reply on HN