NixOS 21.05 • Hacker News Board

Re: NixOS 21.05

#211

Post by tazjin » Thu, Jun 03, 2021, 1:29 PM UTC

aaronchall wrote: post #181

tazjin wrote: post #149

Earlier quoted context omitted.

> I am curious if anyone have experience to share? With one exception (nginx, because it's very well supported) I always just use raw config files and ignore the options. For TVL[0] we've written a bunch of NixOS modules[1] ourselves where the upstream one was either not flexible enough, or deviated strongly from how we wanted things to work. Nix is the kind of tool that lends itself well to solutions that are more c…

Maybe you could propose the improvements in nixpkgs so we can all benefit from them?

In some cases the upstream modules are simply targeting a different use-case. A lot of modules are written by someone scratching a specific itch - ours are no different, but scratch different itches.

I think a better solution (long-term) is actually a redesigned way of doing service declarations where we're dealing with composable bits of data that describe services (so that a module isn't all-or-nothing anymore). Too much on the plate to design that though ...

Re: NixOS 21.05

#212

Post by Nullabillity » Thu, Jun 03, 2021, 2:23 PM UTC

Blikkentrekker wrote: post #210

Nullabillity wrote: post #42

Earlier quoted context omitted.

NixOS also covers package configuration, not just which packages are installed. And because it owns all of the configuration, it can semi-intelligently merge package configurations that are managed in multiple independent places. It can also be used to apply patches to packages (which are then automatically carried over when the upstream package is updated).

> NixOS also covers package configuration, not just which packages are installed. And because it owns all of the configuration, it can semi-intelligently merge package configurations that are managed in multiple independent places. Do you mean system configuration in /etc, or also user configuration in /home? In the latter case I do not see how this can ever be implemented, even if an exhaustive list be provided with…

> Do you mean system configuration in /etc, or also user configuration in /home?

NixOS covers /etc, and Home-Manager covers /home. But in practice many applications support configuration from /etc as well, and you will tend to prefer just managing it from there when using NixOS.

> In the latter case I do not see how this can ever be implemented, even if an exhaustive list be provided with each package in it's description, quite a bit of software will arbitrarily add new files under new names as part of it's confguration.

Hm? If you use Nix to manage the application's configuration then Nix is the only program allowed to change the configuration directly.

> Usually one simply copies one's entire `~/.config` directory along.

Not the same thing. Nix allows you to express relationships between different application configurations (why does program A try to connect to localhost:9267? oh, ripgrep says that program B is binding that port for RPC...), and lets you stack configurations (so that defaults can be updated automatically, or you can change a specific value for a specific machine without having to maintain two completely separate copies).

It's like the difference between giving a new employee access to your source code, vs saying "here's an optimized stripped build, and here's a copy of Ghidra, have fun!".

> True, but this is also a feature of any source-based system.

In the same sense that you can copy your dotfiles around manually, sure. The difference is that Nix allows you to patch the package definition itself dynamically. AUR/PKGBUILD (the only other source-based system I'm familiar with to be fair, not sure if Gentoo handles this differently) allows you to patch the /application/, but you still need to copy the PKGBUILD and backport all upstream changes.

Re: NixOS 21.05

#213

Post by mason55 » Thu, Jun 03, 2021, 2:33 PM UTC

pxc wrote: post #179

mason55 wrote: post #172

Earlier quoted context omitted.

Random nix usage question... occasionally I run into something like this, where the "install" directions are to clone a git repo and then install in an imperative way. What's the correct way to do this declaritively, e.g. in a home-manager or NixOS config? And why are directions like this in the imperative form? I'd think that people working this closely to core Nix would be pushing declarative setup so there must be…

I think this is one of the things that flakes aims to solve. I'm playing around with a new flake-based setup and I'm using flake-utils-plus[1], and I use the overlays builder to make it easy to refer to packages that come from flake inputs in my configuration.nix and similar places, like. I just added the latest Nixops from master to make sure I was giving you a real answer, and I use an overlay like this in my flake…

Wow, a lot to digest here, thanks for the super detailed response! Definitely going to be coming back to this over the next week or two and trying some things out.

> Unfortunately, in the pre-flakes world, you just have to read the Nix code and figure out how to translate things to get the attributes you want into scope

This has been my approach, I always kind of assumed that there must be a better way but at least I feel a little better knowing that there isn't really. I haven't spent much time with flakes because I mostly only use Nix as a package manager/operating system but this helped me see how even if I'm not personally writing packages that I want to re-use I can still get a lot of value from flakes, so getting that setup is probably my next step!

Re: NixOS 21.05

#214

Post by pxc » Thu, Jun 03, 2021, 3:13 PM UTC

lloeki wrote: post #200

pxc wrote: post #188

Earlier quoted context omitted.

> Is [the benefit of this approach] just a matter of it being quicker to do nix-env -iA instead of updating your config and running home-manager switch? That's definitely a factor. I think since I keep my Nix configurations in source control, somehow modifying the configuration feels more ‘official’, and it also usually comes with extra steps like committing and pushing. The other thing I like is that it makes it ver…

> or even what version number a package has In the context of within nix packages that's correct. In the context of nix usage that is not. I start a project, I need it to use Ruby 2.7.x, OpenSSL 1.1, node 14.x because that's what the project is compatible with, and I need that to happen on both Darwin, Linux, on whatever cpu arch. Pinning the hashes of "whatever I built it with" won't work. Worse, some software such…

> I start a project, I need it to use Ruby 2.7.x, OpenSSL 1.1, node 14.x because that's what the project is compatible with, and I need that to happen on both Darwin, Linux, on whatever cpu arch. Pinning the hashes of "whatever I built it with" won't work.

> Worse, some software such as e.g Ruby encodes their platform at build time (because it matters, because #ifdefs) so currently I'm on darwin20 but specifying "ruby" pulls in RUBY_PLATFORM==darwin17. Nix is currently helpless in face of that.

Right, right. That's a real problem. Gentoo Portage has mostly a big monorepo kinda like Nixpkgs, and in it you can find multiple versions of many pieces of software. Maybe the sensible future in the Nix world would be:

1. Our package attributes include version metadata, perhaps through something like ‘subflakes’ within the repo.

2. Nixpkgs includes multiple versions of major pieces of software.

3. Nixpkgs' top-level remains basically as it is now, in that for the most part only the latest version of something is used as a dependency. Alternatively, we use some kind of a ‘lock file’ that gets published with Nixpkgs. This way `nix profile install` still doesn't have to perform any dependency resolution for packages inside nixpkgs, so its behavior stays fast and predictable.

4. You can add version constraints in defining packages for use outside Nixpkgs, in `nix shell` environments, etc.

Does that seem like the way to go for you, or is your ideal picture something else?

Re: NixOS 21.05

#215

Post by balves » Thu, Jun 03, 2021, 4:12 PM UTC

What are people's thoughts on running nix without nixos, using a base system such as Debian or Arch?

It seems like it might be a nice way to get reproducible dev environments, without some of the headaches being discussed here.

Is this a common use, or do people typically just do all-or-nothing?

Re: NixOS 21.05

#216

Post by Ericson2314 » Thu, Jun 03, 2021, 4:13 PM UTC

pxc wrote: post #194

Ericson2314 wrote: post #138

Earlier quoted context omitted.

s/to nix/of flakes/, to be clear

what do you think of the strategy of stabilizing just the input schema for Nix flakes, which is all that's required for pure evaluation, then stabilizing each component of the output schema separately as those components are called for by specific features of the Nix/NixOS CLI?

That's a neat idea and improvement for sure. I'm pretty pessimistic about the outcome here, and perhaps what you said is a most realistic turn.

There is a larger issue that still irks me: all this stuff is based off Cargo/Cabal/etc., but I think that's fundamentally the wrong model for our purposes. Historically every C package is a snowflake and we do need to package them individually. But as language-based ecosystems take off, we increasingly can auto generate everything we need, and our Nix code is not the bricks but the mortar.

More concretely, the things I do with nix-thunk / Niv today don't really correspond to package boundaries that much, and if they do those repos might not contain any Nix code because I callCabal2nix them. callPackage-style "I am a function of my dependencies" is right, but when those dependency derivations don't align 1-1 with my nix-thunk / niv usage or need extra preprocessing à la cabal2nix, the fundamental concept of flakes breaks down.

Re: NixOS 21.05

#217

Post by gmfawcett » Thu, Jun 03, 2021, 4:29 PM UTC

takeda wrote: post #197

Mic92 wrote: post #151

Earlier quoted context omitted.

If you want to build custom images just use https://github.com/nix-community/nixos-generators It's documentation is on point.

Would it be possible to add a minimalistic image that contains app, kernel and essential packages? Like what you would get when building a docker container or using the not-os repo that I mentioned earlier. I think having mini images would be awesome.

Re: NixOS 21.05

#218

Post by pxc » Thu, Jun 03, 2021, 4:37 PM UTC

Ericson2314 wrote: post #216

pxc wrote: post #194

Earlier quoted context omitted.

what do you think of the strategy of stabilizing just the input schema for Nix flakes, which is all that's required for pure evaluation, then stabilizing each component of the output schema separately as those components are called for by specific features of the Nix/NixOS CLI?

That's a neat idea and improvement for sure. I'm pretty pessimistic about the outcome here, and perhaps what you said is a most realistic turn. There is a larger issue that still irks me: all this stuff is based off Cargo/Cabal/etc., but I think that's fundamentally the wrong model for our purposes. Historically every C package is a snowflake and we do need to package them individually. But as language-based ecosyste…

I agree with the general orientation in favor of the monorepo and transforming package definitions from repos that don't know/care about Nix, then aggregating them. I think the vision where we use Nix mostly by way of Nix code that has propagated into the source repos of various projects, and we simply use that code directly, probably gets it backwards.

> callPackage-style "I am a function of my dependencies" is right

What did you think of Eelco's presentation at the most recent NixCon where he considers defining packages as NixOS-like modules instead of bare functions?

Re: NixOS 21.05

#219

Post by tgamblin » Thu, Jun 03, 2021, 4:50 PM UTC

_huayra_ wrote: post #41

e3bc54b2 wrote: post #35

Earlier quoted context omitted.

I agree on every single point. I'd love to make GuixSD my permanent home. But, Guix is not just Nix with better language. It comes with its own baggage elsewhere. Guix repository has way wayy fewer packages. Some of the most common ones like the plasma-desktop are absent. Proprietary applications are a no-go. Even if I set up nonguix, I'm warned that that cuts off my support in official channels. As an Optimus laptop…

Yes, if Guix were "Nix but with Scheme" I'd go for it in a second. Unfortunately, although both Nix and Guix make hard choices about things (e.g. the init system), at least the choices made by Nix are more livable day-to-day. As to why Nix wasn't some system written using Haskell (for actual language features that is also lazy) or Prolog (for its whole thing about solving constraint-based problems all over the place)…

Guix and Nix don’t actually solve constraint problems, though. By design, they omit the dependency resolution that other package managers do, and humans manage the dependencies. If you want to change versions, you need to do some hacking to update things and propagate requirements through the package graph.

You could think of Spack (github.com/spack/spack) as a nix/guix-like model, but with a solver. Spack uses ASP (which is prolog-like but reduces to SAT with optimization) but packages are written in an embedded python DSL.

Re: NixOS 21.05

#220

Post by takeda » Thu, Jun 03, 2021, 5:39 PM UTC

sph wrote: post #105

acgkmopvvgvmgv wrote: post #87

Earlier quoted context omitted.

Nix and similar projects are all going to be eaten alive by immutable distributions, Flatpak and new projects - that might work just like Nix but get the user experience right, and make packaging and maintenance easier. And no I'm not saying they do the exact same thing, have all the same features or target the same type of users. For the developer tools side I like what Shopify did but I would never recommend that t…

I'm out of the loop, what did Shopify do? EDIT: ah, you're probably talking about https://shopify.engineering/shipit-presents-how-shopify-uses...

I hate that they mentioned about ru.nix, published it on github for short time and then unpublished it[1].

[1] https://github.com/Shopify/runix/