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.
Do you have a link to where I can read about using Nix as purely a package manager? Or a minimal example showing how a Nix config looks if used in this manner?
I agree that there's a huge documentation and user awareness gap, but NixOS is obviously possible to configure this way so it's definitely possible.
Might be room for a tool that exposes just the configuration management side of Nix in a more approachable way... on the other hand it would be a bit silly to use nix for conf files and not also for the underlying packages.
I understand it allows for stable binaries, without dependency hell, easily installable, possibly multiple versions of the same package; and for easy rollback of the installations. Because code modules are versioned by hashes of their full dependency tree and build options.
But configuration files?
I once installed the Nix package manager on my Ubuntu, and installed some apps with it. Nothing worked. Because some files I have in /etc/ were not compatible with Nix versions of the applications. Those configs were about some deep mechanics of X-related libraries. I never edited them and I don't understand their function.
So, it was impossible to use Nix packages side by side with my Ubuntu. And I suspect the same can happen on plain Nix OS with multiple versions of one package.
Probably I am missing something, but that does not look perfect.
I only know Guix, not Nix, but I found it mostly harder to make package definitions for that than to backport rpm and dpkgs, at least for requirements that aren't radically different from the base system. (That's nothing to do with Scheme, by the way.)
Then, if you're bothered about security, it's not clear that having to keep track of two different packaging systems and possible interaction between them, is a win.
What would seem most useful would be a compile-time-typed language (perhaps with some inference propagation, for convenience) that existing Nix code could be translated into, maybe even while emulating execution to discover the actual types to annotate with. You have the advantage that all existing production Nix code is known to terminate in short order.
Then, you could generate a new version of the entire 30,000-strong package collection automatically, with the new language swapped in in place of the Nix code, which could then be abandoned.
maybe if someone would build a tool that pulls from Ubuntu repository and recreates an equivalent nix package.
come to think of it, there is nothing in aptitude that prevents this kind of an approach (including the unique hash paths). It will get you to 75% of Nix functionality, which IMHO is good enough.
I dont think Redhat.or Ubuntu will want to do that though. Their business model revolves around the walles garden.
I remember reading that nix unlike all other distros can install multiple version of the same package and I want this feature, but I guess programming a package config might be too much for me. Maybe I'll try nix package manager then.
But I have no idea how I would build a config structure for an application using Nix... It seems very powerful so I'm sure it's possible, but I just have no idea where I'd start for this specific use case.
Whereas this documentation for Pkl is entirely about that use case.
Mhm, doesn't sound all that similar to me. This looks like something that needs to be maintained on a per-package basis as a fairly ad-hoc solution for different library versions, in Nix the whole thing just falls out of the way it's set up in general.
Other than daemon implementation and design ideas that migrated from/to Nix/Guix, is there a way to write a package in Nix and use that derivation in Guix or vice-versa?
I ask thinking if it would be possible to somehow leverage the work on packages from on project to the other.
This is pretty neat. I wonder if the idea could be extended more generally to "un-nixify" packages - i.e. replace references to the nix store with relative paths.
I can envision some applications for distributing packages for non-nix systems while still relying on nix to build them.
This likely wouldn't work on practice. Nix is aggressively lazy, so if you just want a single package, you don't have to evaluate the builds of all 60k+ packages, just the package you wanted and its dependencies.
This just might be me as a functional-programming-maximalist, but I do not like imperative languages for configuration management. You implicitly have to hold the execution state of all actions to know what is going on.
Interesting, thank you! So that means programs are sometimes patched to look for configs in nonstandard locations generated by Nix during installation time. But then if I wish to change any of those configs (maybe to change one of the defaults)... I have to copy them, make my modifications, generate my own package for them, and install them to wire them in as substitutes for the existing packages. Then when the upstream package changes the config file, I have to generate a new package with all the conflicts manually resolved, right? It seems a bit of an arduous process, though I do see the appeal.
Yeah I really need to actually sit down and learn Nix, seems like it can solve this in a more general way for cases where the thing you want to run is packaged for Nix already.
Yeah that's super helpful for NixOS configuration options. What trips me up more is configuring particular packages. Usually it's where I want to configure a particular version or github commit of a package for some reason (usually I want a bug fix).
However, a bunch of packages are defined in some bespoke way with various custom config inputs that generate other bits of config and generally are hard to understand. Thinking it through, I'm not sure it's possible for the OP's tool to solve this particular problem.
The primary value in nix is in the packages, not the configuration language and not the prebuilt cache system.
If one were to fork the project, the sensible way to do that would be to build a nixpkg-compatible alternative system that doesn't have some of the design flaws (such as a global non-discoverable configuration namespace and an underdocumented custom functional programming language...).
I don't think anyone's gotten together the hours to do that. But I'd certainly love to build an immutable, repeatable system using a Python or Kotlin config myself.
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.
reply