> Nix often scares newcomers and experienced devs alike, because it proposes a fairly radical overhaul to how we think about package management and how we run software in general.
I am not sure this is the main put-off of nix.
Ideologically, I love nix. The syntax/language itself is a massive barrier IMO.
I use Nix for personal projects, but I prefer the experience of Devcontainers. They're easier to understand and debug (for me).
I'm watching eagerly the work being done by the ostree/rpm-ostree folks who are also trying to solve for a similar problem. Hoping to see something like "Nix but with YAML/JSON" come out of that.
... kinda like people who pretend that Zig is a competitor to Rust, and conveniently forget to mention that it does not promise memory safety.
I've been seeing a lot of "steal their thunder" type project positioning lately when something is a radical leap forward but requires major effort to learn -- like nix or rust.
People seem to have picked up on a strategy that if you can put together something inferior but easier to understand (zig doesn't need a borrow checker because it's memory-unsafe; ostree doesn't need a language because it ignores dependencies), and market it as an alternative to the radical thing, a much larger group of people will rally around the simpler thing instead of the radical thing because they feel threatened by the new thing that can't be learned in a weekend or even a week, and using only "20%-time" would take six months to master...
I'm going to get downvoted to hades for this, but it's true.
I don't see ostree promote themselves as an alternative to Nix. The GP linked to an explainer of how OStree differs from a bunch of systems, not really a promotional page. And in general OStree's use case is different to Nix so I don't think it competes.
You may be right that this is a pattern, but I don't see it in this case.
... kinda like people who pretend that Zig is a competitor to Rust, and conveniently forget to mention that it does not promise memory safety.
I think that this comparison is unfair. First of all, the OSTree documentation doesn't pretend that it is something like Nix. It's an object storage for operating system images. Secondly, in contrast go Zig, OSTree most likely wider use/deployments than Nix, since it is used by Fedora CoreOS and Fedora Silverblue.
That said, even though Nix and OSTree are not very similar. For users, there are similar benefits: an immutable system, atomic upgrades/rollbacks, etc.
I think it is also much more likely that OSTree gets into the hands of millions than Nix.
(Disclaimer: I like Nix a lot and am a contributor to nixpkgs.)
> I'm going to get downvoted to hades for this, but it's true.
Yes, because it has nothing to do with Nix, but it's just your own off-topic crusade, and being concerned that when someone tries something different, they're "steal[ing] the thunder" from your own favourite pet project. Talk about feeling threatened.
We can do better than having cults around our little language or package manager but instead learning to appreciate the little differences between each project. Perhaps the solution is in the intersection between the two.
The language is small enough that there's no way it's a problem. It seems less complicated than YAML, a couple hours to pick up at most.
I have a NixOS setup on my desktop and use Nix for some projects, but only maybe a week or two of experience. And the language was never an issue.
The bigger problem is the standard library is a sprawling mess: Understanding what options are available or how to get your thing to build by analogy with someone else's, requires digging into nixpkgs with no good tool support.
If you did a line-by-line port from Nix to YAML or Python but kept the standard library exactly the same, it would be even harder to understand.
Yes, nixpkgs desperately needs to be split, at least into two packages:
- stdlib
- packages
The stdlib could also include builders and language frameworks, or they could be split even further.
Then treat the stdlib the same way as it is treated in any other language (make it stable, not changed frequently and make sure everything is documented with the release).
That would reduce the need of reading source code to use nix.
I am not so sure about that. Nixpkgs is a big ball because it is the final integration point. And I do in fact find myself refactoring individual packages and the infra at the same time.
https://github.com/NixOS/rfcs/pull/109/ I wrote to hopefully make the lang2nix packages work with Nixpkgs. I think this would achieve most of the benefits of what you propose: cleaner separation of infra vs vs ad-hoc per-package stuff, while still retaining the flexibility of the monorepo.
The goal is to work with upstream developers so less and less ad-hoc crap is needed. Then the one repo ends up "all stdlib no packages", because the packages are basically autogenerated!
I have mixed opinion about this. I mean, I understand that there are increasingly applications that are getting harder and harder to package, but if there are tools that could just parse lock files and build a project without any work, in that case why even package it, one could just have function where we could point to SCM repo and it would fetch and install the application.
I'm still not fully understanding what import from derivation really mean (technically) is it an ability to fetch the source from repos during evaluation?
If so, that is an issue. If one tries to use Nix in environment with repos that require authentication it is a huge pain. There was a workaround once with passing SSH configuration, but it was removed.
I also think your RFC is orthogonal to what I suggested. I think #1 issue with Nix is steep learning curve, and huge part of it is documentation that is not up to date. The thing is, as others said, Nix is great when everything works, as soon as you step into something that's not as common suddenly things become really complex, because documentation is not enough, one has to dive into nixpkgs which is very complex.
> Nixpkgs is a big ball because it is the final integration point. And I do in fact find myself refactoring individual packages and the infra at the same time.
That's actually the problem I'm talking about. Because this infrastructure code is constantly changing => that makes the documentation be not up to date => makes Nix more difficult for others to start using it. You don't have difficulty with it because you know it inside and out, I know enough to usually find what I'm looking for, but from my own experience I remember it was really hard to get to the point where I'm and I'm still not that great at it.
Normally if that was happening in any other language it would be considered to be not ready yet for wide use, but Nix does want to be used and think this is one of things needed. Even with up to date documentation it there are still difficult things, but at least it would be huge improvement. Imagine if Go or Python sdk was not up to date and the way to learn it would be studying sdk's source code. It would be a drastically different programming experience and I doubt people would call those languages beginner friendly.
I don’t want to be dismissive. “nix but with yaml” is kind of like saying “rust but without borrow checking”. if you think you can approximate what Nix is capable of with YAML and be less complicated, I think you’ve missed the point. what makes Nix powerful is that it is built on the back of an actual programming language. it’s fundamental to the whole thing.
the language itself is surprisingly simple. the difficulty people have with it is that it’s functional, not that it’s nix. I don’t think most sys admins are fluent in functional programming, so it’s a huge turn off and learning curve.
if you approach it as three problems: learn the basics of functional programming, learn the syntax of the Nix language, and only then learn what a derivation is and how it works, it will be a lot easier to approach. at that point the nixpkgs library starts to make a LOT more sense.
I understand that’s a lot to ask when you just want to install some packages, though. It’s a tricky problem.
> what makes Nix powerful is that it is built on the back of an actual programming language. it’s fundamental to the whole thing.
I think I agree with this.
> the difficulty people have with it is that it’s functional, not that it’s nix.
No I don't think that's the problem people have with it. Speaking for myself the thing that's hard about Nix is first and foremost the bad error messages and secondly the complexity of idioms used in nixpkgs. If you stray just a little bit from the happy path, you're liable to get a ton of very arcane problems, and the error message often has nothing to do with the actual problem because a lot of the idioms used in nixpkgs end up doing clever things with Nix that work well when everything lines up just right, but blow up when just a little bit is wrong.
The functional parts of Nix can be obstacles for someone new to functional programming, but when something goes wrong the developer has a clear sense of what is wrong ("ugh why is this immutable?!") even if it's not clear how to fix it. The sheer complexity of nixpkgs though can cause breakages in ways that don't make it clear at all what went wrong.
There are a variety of ways that this could be fixed either in concert with changes to the language itself, or whole-scale changes to the interpreter/compiler.
you’re right. I guess I should qualify that with: what makes the language more difficult to approach as a newcomer
once you’re in there, there’s a ton of warts, of course. I just hear complaints about the syntax so much that it really seems like people are more caught up learning functional programming than Nix. which makes sense, since most people who would need Nix spend their time writing Bash and Python
I think the problem is that the bad error messages make it unclear whether something is a syntax issue or a nixpkgs issue (this is somewhat worse with the dynamic nature of Nix, although I personally don't actually think Nix really needs static typing all that much, but that would be one viable way of fixing this).
One reason is that Scheme has Emacs modes that connect to a live system for precise jump-to-definition, etc. This works with Guix and is extremely convenient. Scheme's metaprogramming also enables Guix's beautiful system of code staging, G-expressions.
> One reason is that Scheme has Emacs modes that connect to a live system for precise jump-to-definition, etc. This works with Guix and is extremely convenient.
Those are all valuable things, but I don't think that would actually be hard to implement for the Nix language either. Just no one bothered
> Scheme's metaprogramming also enables Guix's beautiful system of code staging, G-expressions.
Yes not pasting together strings for bash would be nice, but with all due respect to scheme's metaprogramming, which I do indeed highly respect, I view this as fairly orthogonal.
From a quick glance, g-exps don't have much binding structure? That means hygiene and other things are not as useful, and just doing
["see" "I" "can" "sexp" "too"]
in the Nix expression language isn't actually so bad.
With G-expressions you can splice in computed store values, e.g. the computed output location of a package. I recommend the paper[1] explaining why they exist and what alternatives they replace.
It's not purely a language thing per se, i.e. there are ways the language could change minimally but error messages could have a huge leap in improvement. However, certain idioms in the standard library might need to change, and certainly changing the language at the same time can improve the error messages even more.
I have only a little experience with Guix (replacing Nix with Scheme), so I'm not very confident in this, but the shallow impression I have is that Guix's error messages are not much better.
For me it's a total lack of any description of the nix language. I just have no idea what I'm looking at, and nowhere (last time I looked, which I admit was some time ago) explained what tokens make up the language. Some showed that parts of the syntax were optional, but not what they meant.
Occasionally I'd find a guide that describes in English what a given example file is doing, and it kind-of made sense, but wasn't clear how it mapped to the file shown. There was a lot of magic going on with no explanation how it was getting there, so I could only assume there were semantics tied to some of the syntax that the writer assumed you'd eventually figure out... But they were just abstract enough that it didn't make sense in a way I could duplicate.
It's not perfect and I raised some issues about fragments being written from the perspective of someone who knows the system - but it's definitely good enough for learning the language.
The problem is not the language but the “standard library” used by it, which is quite ad hoc and organically built.
The language may not be the most intuitive at parts, but I feel that it is not the actual problem people have - I think what trips up people (me included) is that one pretty much grep for a similar package to be able to start doing the work. Why does a python derivation require this function instead of the generic one, what are the package names, etc. Some stricter structure would be welcome, in my opinion.
> For me it's a total lack of any description of the nix language. I just have no idea what I'm looking at, and nowhere (last time I looked, which I admit was some time ago) explained what tokens make up the language. Some showed that parts of the syntax were optional, but not what they meant.
I don't think the Nix language requires understanding of functional programming. Overall, it's not so different from JSON. What is different is that it provides a few programming language constructs on top like variables, functions, and conditionals. This enables developers using the Nix language to properly abstract complex configurations in a comprehensible way, thus avoiding the pitfalls of writing JSON and YAML by hand.
idk, as a part-time Haskeller, I think Nix-the-language kinda sucks (tho not enough for me to not use nix). IMO the big huge thing is really inconsistent nixpkgs docs; compare linkFarm and symlinkJoin's docs, for example. I wish there were some way of getting nice autogenerated docs, but I don't think we're gonna get there without either adding some kind of type system or having a pretty strong review requirement that's actually enforced, and doing that for a year or more...
Plus the nixpkgs and nixos docs are generated from some weird hybrid docbook-markdown that mere mortals (well me at least) can't get to build. So we are stuck using the makes-my-eyes-bleed font on nixos.org, and the gigantic mile-long single-page manual format (which is nice sometimes, like for searching, but other times you want a TOC sidebar).
The documentation for the nix language is all done in mdbook, and is beautiful and easy to read. I wish the nixpkgs/nixos manuals were like that.
AKA the curse of macOS designers that have that setting that makes all fonts a little bolder, so they think 300 weight is perfectly acceptable for a documentation site, while everybody else have to strain their eyes to read too thin a black font on eye watering white for hours.
Just go on nixos.org, remove the font-weight: 300 and see how much readable it is.
> the difficulty people have with it is that it’s functional, not that it’s nix.
My experience is that the difficulty people have is with Nixpkgs as a library/codebase rather than the language itself. Poor error message, unclear abstractions, lots of things managed through implicit conventions rather than in the language itself... it's a massive legacy codebase with a lot of internal inconsistency and some questionable practices. I'm convinced that if you had a magic codebase-cleaning wand and kept literally everything else about Nix (the language, the model, derivations) the same, you'd fix like 90% of the problems people have with the system.
maybe that’s it; maybe it kind of sits in the middle where it tries to please everyone and ends up pleasing no one. not a great functional language, but functional enough to confuse you if you’ve never done functional and are expecting JSON.
I've written this before. The issue is not because it's functional at all. That's a proximate explanation that's just plain false.
Everyone I know that has tried Nix was a functional programmer first. Nobody had a good experience with Nix though.
If I could describe my issues with Nix it's that:
1. The syntax is odd. It's usually better not to stray too far from common programming languages if you want your language to be accepted.
2. You often find two examples which work individually, but they use a different way to do things, so it's hard to get them to work together in the same configuration.
3. A lot of examples depend on some specific functions, which are hardly explained at all. There seem to be a lot of these special functions that make it very hard to make a mental model you can work from.
4. The error messages are worse than C++ templating errors.
5. At least last I checked the documentation was really lengthy, but never gave a good overview of the language, only gave some inconsistent examples instead. In the end you don't feel like you learned something.
It's a higher level issue, declarative vs. programmatic environment control. It isn't that sysadmins don't understand programming, functional programming, etc.--everyone is devops these days. It's that in the world of system administration we've gone through many waves and trends with significant backlash against complete programmatic definition of environments.
In the old days you'd exec a pile of shell scripts to go out and put your servers into the state you wanted. It was brittle, painful to understand, etc. Then things evolved into declarative definition of environments with tools like ansible. Now you just define the state of the world you want and ansible or other tools do the work to get the world into that state. This has evolved even further into declarative definition of entire distributed systems with kubernetes--you write out a pile of YAML that defines the state you want and kubetl and k8s controllers take care of making it happen.
So there are definitely people that understand the value of functional programming, but don't want it to define their environments. I don't want to have to grok someone's 'clever' solutions to figure out that ultimately they just want package x, y, z and software foo installed. I just want to list what I want and let the tooling make it happen.
> I just want to list what I want and let the tooling make it happen.
That's just what Nix does?
It's very much more declarative than any system I've seen. Yes, k8s turns your declarative manifest into running processes, but how was the image built? There's a huge gap there: you refer to container images by name, not by a description of the software you want them to contain, and then hope that some other process has built the image correctly. Nix can close that gap and take declarative all the way from the service manifest down to the git commit of the compiler used to build your binary.
The comment you're replying to describes concerns about maintenance burden from the programmatic nature of Nix.
I think "declared in YAML, pointing to a Docker image", and "declared in Nix, pointing to some more Nix elsewhere in the codebase" is relatively moot to this point. (If you wrote the image, you'll know what it's expected to do; if you don't know the Nix you're pointing to, it's as opaque as a Docker image).
Configuring with a program vs using a plain structured file have different trade-offs.
Does anyone write k8s manifests in raw yaml? They're so complicated that they're generated using some templating language (helm or kustomize or whatever is popular these days, I'm a little out of the loop). So you still have something programmatic. Think of Nix as just a better and more principled templating language. (I mean, look at NixOS configs: they're much closer to "plain structured files" than "programs".)
The promise that I see (I haven't seen this fully realized but it should be possible) is that instead of yaml plus some ad-hoc templating language plus dockerfile plus makefile, everything is in a single language top to bottom.
> the language itself is surprisingly simple. the difficulty people have with it is that it’s functional, not that it’s nix.
I wrote down "what I wish I knew when learning Nix", and realised what had initially confused me:
Some people are confused by immutability when learning functional programming. e.g. Programs involve changing things, but then immutable stuff doesn't change.
With Nix, packages get built and installed to the store. In other solutions, this is done by running a command like "install package", or by having some file describing the package and running "install this"... but with Nix, packages are so integral to the language that they're built as part of just evaluating the language expressions, and (before flakes) the language didn't really have a "main file format" the same way that programming languages do, or that Terraform does.
With functional programming, pure functions have no side effects. With Nix, an implicit side effect of evaluating code is that packages are built.
Sort of. There are no real side effects, just lazy evaluation. Every entry point into `nix build` evaluates one expression to produce one output, but in the process, ends up evaluating the outputs of all the dependent expressions as well. The Nix store essentially caches the results of these evaluations, which looks very much like a traditional package manager "installing" packages to the file system.
It's kind of like how an implicit side effect in "normal" FP languages is that memory is being allocated.
The nix garbage collector will even free up disk space by deleting unreferenced packages just like a garbage collector freeing memory by deleting unreferenced values.
A bigger problem is that the command-line utilities (what git calls "porcelain") are full of jillions of inconsistencies. Some tools (nix-env) read ~/.nix-defexpr, others (nix-store) ignore it. Sometimes arguments are interpreted as filenames, sometimes as attrnames, and other times as a search query that nix will use to grind through some big list of package names.
The new "nix" command with subcommands ("nix env" instead of "nix-env") is much better, but has been stuck in "experimental status, breaking changes may occur at any time". Stabilizing the nix command syntax and deprecating nix-env/nix-store/nix-instantiate would go a long way.
> the difficulty people have with it is that it’s functional, not that it’s nix
Not really - functional languages are ok. The problems I have are nix-specific:
- for documentation you need to read the source
- there's no debugger
- there are no sanity-checks in the system which means that some internal function deep down the stack says "attribute never_heard_about_it missing" and you have no context how it got there
- there's no type checking which results in the previous error on attribute foobar while you set attribute fobar and have no idea why things aren't working (or set {system}.{package} instead of {package}.{system})
> I don’t want to be dismissive. “nix but with yaml” is kind of like saying “rust but without borrow checking”.
I mean... your metaphor cuts both ways? A lot of work went into making Rust's borrow-checking non-intrusive, or at least softening its edges.
The big improvements were lifetime elision and non-lexical lifetimes, but there's also a ton of compiler errors for common cases that explain what went wrong, and often suggest an easy fix when there is one.
Last time I checked, Nix didn't really have this. If you get the syntax wrong, it doesn't tell you "oh, you tried to get 'ripgrep', you probably meant 'nixpkgs.ripgrep'".
> Last time I checked, Nix didn't really have this. If you get the syntax wrong, it doesn't tell you "oh, you tried to get 'ripgrep', you probably meant 'nixpkgs.ripgrep'".
I get where you're coming from but as it stands there is no universal description of what "nixpkgs" means in this context. It's a channel, defined only in the context of your environment. Your nixpkgs isn't my nixpkgs. It's just a channel label.
Imagine you typed
curl "PoignardAzur"
compared with entering the same value into your browser's address bar. Would you expect to end up on your HN profile page in either case?
I think what you're missing is that instead of providing the convenience behavior you're looking for, a more powerful primitive is available. Any other package manager has a bloated song and dance where if you want to install something not in the official repo, you either:
- download and install it manually
- add a new third-party repository and install it from there.
Then, whenever you perform a distro upgrade, you have to repeat the entire process because the repo has changed, subtly.
Instead, nix eschews this concept by allowing you to install whatever you want. Imagine running Ubuntu 18.04 and wanting to install a package from Ubuntu 20.10. Have fun with that! Nix not only makes it possible, it makes it as easy as installing anything else.
I now consider "foo install ripgrep" a mistake and an anti-pattern. I now find those tools annoying to use. Could nix be better? Certainly, but you're really giving me a "it's different so I hate it" vibe. Give it a chance.
> I think what you're missing is that instead of providing the convenience behavior you're looking for, a more powerful primitive is available.
That's great, but I still want the convenience behavior.
> Give it a chance.
I tried. I kept getting papercuts, and things that were easy on PopOS were annoying on NixOS. That wouldn't deter me if I needed to use Nix, but as it is PopOS works perfectly for me and I have no reason to switch. I might still try out of curiosity, but I'm honestly not feeling that enthusiastic.
But that kind of response that boils down to "you just think that way because you haven't tried it" or "the reason the UX is so incredibly obtuse is because of the underlying model" seriously annoy me.
You can have plumbing and a porcelain. Nix currently is lacking on the porcelain side. The idea that you have to study the entire programming model of an OS (not just vaguely understand it, which I do, but study it) to use it, and if you think it's not worth the effort, it's because you haven't tried it yet, is inane.
I'll be honest: I don't understand why you wanted to try NixOS out in the first place. It sounds like Pop!_OS works for you? Great! Enjoy. It doesn't work for me.
Not that you're asking, but I found your review pretty uncharitable. You pretty clearly don't want any of the benefits the Nix ecosystem provided. NixOS is not competing with Pop!_OS, and I wouldn't recommend to non-technical users. It really sounds like you want to use snap or flatpak, so I'd recommend those -- they also work well on NixOS.
As for your review, in particular:
- you changed the desktop environment from the default, which is fine, but a lot of your problems are the result of that choice. The default is KDE, and I find it works perfectly well. How does Pop!_OS fare if I install XFCE?
- lengthy rant about /bin/bash vs /usr/bin/env bash, I found boring since the latter has already won as far as I can tell, and righteously so. The whole point of NixOS is to deprecate a traditional FHS, and then you complain about the lack of FHS. Okay.
- You give up on Steam immediately. I run Steam rather successfully and I've managed to play more games on Linux than ever before, I can count on one hand the number of games I've been unable to start, and it's usually because of shitty DRM.
- you don't understand the difference between nix-env and configuration.nix, so I don't think you read the manual.
- you just want to use existing dotfiles/configuration instead of learning how home-manager workapo
- you describe difficulties getting the VLC developer environment set up, but the instructions were not written for NixOS. What are you hoping to accomplish? The Nix way would be to open a shell for the VLC derivation, which works fine without installing Docker. You didn't even try this.
- you somehow don't mention the most obvious pain point everyone runs into, which is that you can't usually trivially download and run binaries as there is no FHS, so binaries don't know where to find runtime dependencies.
> The idea that you have to study the entire programming model of an OS (not just vaguely understand it, which I do, but study it) to use it, and if you think it's not worth the effort, it's because you haven't tried it yet, is inane.
Have you used MacOS before? How did you get started with Linux? Why is Pop!_OS intuitive to you?
You don't need to study, but you need to develop and foster an understanding of how the systems operate. This has always been true. This system is different, but you want it not to be. You're installing your own operating system but then expect to be pandered to. You're seriously exaggerating the effort involved.
Ultimately this isn't a productive conversation. You're not interested in change without a seamless transition, which NixOS does not purport to offer. It's been around for a while, sure, but it's been a pet project for most of its life. Debian is nearly twice as old, and Ubuntu built upon Debian, and Pop!_OS built upon Ubuntu. They're all pretty much the same. NixOS is quite different. In time, we'll see the same polish along with spin-off distros.
I recently briefly tried Nix and yeah the language seems a bit tough with not too many resources floating around. I really don't want to learn a whole language just for my package manager. But then I discovered Guix which is inspired by Nix but uses Scheme instead of a custom thing. Seems more sensible and easier to understand as I know a little bit of lisp already.
You need a strictly pure functional language to do what Nix does. It's able to determine if something is already installed (in a specific state) because it calculates a hash of the output. Side effects throw a wrench in all of that.
The language doesn't need to be lazy. Strict languages model laziness via explicit lazy values. For Nix, this would be some kind of explicit package type. Side effects are problematic though.
I feel like a logic programming language (e.g. Prolog) would be a better fit for what Nix is trying to do than a functional one like Nix. Of course those are even less familiar to most devs than functional languages, so it wouldn't solve the "weird new language" issue.
Guix was a unmitigated disaster for me: after at least an hour of tinkering I got the installer ISO to boot. Not long after linux-libre managed to install itself again, and my machine stopped booting. Not practical, at all.
> The syntax/language itself is a massive barrier IMO.
But oh boy was this a joy. The Nix language isn't that bad (Dhall has the potential to surpass it), but Guix gave me seriously rich error messages, and lisp works great with almost any editor.
Overlays and home-manager just grew out of nix and either lack ergonomics or decedent error messages (compared to Guix). Flakes improve the situation, but nix still feels "all over the place."
I run Nix on my desktop, but I'm actively working on a Dhall-based replacement.
To be clear: I have extremely high praise for nix, and I'm getting nix-darwin going at work for engineer onboarding. That being said, it feels more like a research project. It pioneers some extremely important ideas and, by necessity, some of those ideas are "bolt-ons" and truly just feel like a proof of concept. Guix, for example, has home-manager built right in and doesn't suffer from the error message issues that home-manager does.
I used Arch, btw, and AUR was truly a thing of beauty. PPAs (of Ubuntu) are, in theory, even better. Have you seen the sheer amount of effort it takes to keep nixpkgs going?[1]
Home-manager, amazing thing that it is, has several issues. From their own documentation:
> Unfortunately, it is quite possible to get difficult to understand errors when working with Home Manager, such as infinite loops with no clear source reference. You should therefore be comfortable using the Nix language and the various tools in the Nix ecosystem.
Flakes? Experimental:
> Nix Flakes are an upcoming feature of the Nix package manager.
I also think it should be possible for the mainline (e.g. nixpkgs) to import a flake: the nixpkgs maintenance nightmare has to end. Dhall can do that, and will even verify it with a hash[2].
They came up with extremely important ideas, but the same ideas taken as a whole (instead of iteratively) could be combined into something far greater.
I guess that the biggest challenge such a project would face is providing a smooth transition for package maintainers: if they have to cut-over or maintain two configs it will be much more difficult to retain them.
So my thought is an that maybe you should use a staged approach where your dhall packaging config design can be compiled down to nix, making it easy for existing nix packages to convert and still be backwards compatible with nix, then develop a dhall-only implementation that consumes the same config but eliminates the intermediate compile-to-nix and evaluate-nix steps. I don't know the design, so this approach may or may not be reasonable.
Regardless, I'm quite interested in a nix-like solution with configs written in Dhall.
Ideologically, I love nix. The syntax/language itself is a massive barrier IMO.
I use Nix for personal projects, but I prefer the experience of Devcontainers. They're easier to understand and debug (for me).
I'm watching eagerly the work being done by the ostree/rpm-ostree folks who are also trying to solve for a similar problem. Hoping to see something like "Nix but with YAML/JSON" come out of that.
https://ostree.readthedocs.io/en/stable/manual/related-proje...
reply