I’m definitely interested in the build system / package manager. I have (idly, in a daydreaming sort of way) considered building something like it myself.
I tried to get into Nix recently, but found it difficult to accommodate my workflows within its uncompromising nature. My goal was to set up a reproducible development environment, where anyone at my company could easily get set up to work on our code with a single (or concise set of) action(s). I also tried to use home-manager, which I have heard might have been a mistake.
Anyway, Nix is really only designed to manage the entire world. I wasn’t able to use Nix to build a development environment where other developers and I could work inside of it using our existing tools and workflows, including other package managers that want to mutate things — it seemed that Nix was all-or-nothing. This was too disruptive and a large barrier to adoption for me.
I would love a tool designed for reproducible builds and development environments that can compromise, and do as much as possible immutably while allowing for local mutation on top. That can be a package manager, but also make it easy to use existing package managers too — with the understanding that these other package managers are typically also able to reliably reproduce a build, within their own mutable state. It’s OK if this potentially needs to mutate “the system” in the process to try to reach a goal state (e.g. installing system-wide package managers, xcode, etc.)
Nix really did not seem to be designed to allow me to use other package managers inside it like npm or cargo. It has some support for directly vending packages from those via Nix itself, but that’s not what I want right now; it’s too disruptive to my workflow. We already have all of the build reproduceability that we need via those package managers and via a container based build process. Still, a fair number of development and operational tools are required to develop the software, and I would really have liked a one-click way to set up a development environment that doesn’t require a container (which is not native on Windows or MacOS).
(I admit that it is possible that this idea fundamentally could not work for technical reasons, but it seems plausible that it could.)
Another challenge that I had was with the complexity of the Nix config and file format. It’s basically a programming language, and there isn’t always one right way to do something. That made it considerably more complicated to solve tasks that would be just a single line command if I was using e.g. Homebrew to solve the same goal (brew install xyz).
From a user experience perspective, I would like a tool that provides a simple command line porcelain for mutating the state of the environment, while tracking it immutably under the scenes, so that it’s reproducible. For example, “cmd install foo” should add the “foo” package to my environment (and rebuild it). So at the end I have a declarative description of my environment contents, but I can build that configuration using a sequence of familiar install commands.
I admire what Nix is trying to do, and see a lot of merit to the approach for defining an entire machine’s state immutably. For managing and defining the state of servers, it seems like a great idea. However, the cost to adopt it seems high, and the value would probably be marginal in our case, since we don’t need to manage servers to deploy software (instead deploying only containers); and since existing package managers provide a way to build those containers reproducibly. But containers aren't ideal for defining the tooling used by an interactive local development environment.
Before your comment, my design could not do that. After your comment, I'll make sure it will.
As a build system, it can incorporate other build systems and run them natively. It only makes sense that it should do that for package managers as a package manager. So as long as you understand that most other build systems give you opaque binaries, I can make that happen.
But on the other hand, I think I can make your mutable environment idea work and cross-platform to. My design will require that the environments all be on the same disk because it will use hard links and a SQLite database, but those work on any platform.
But anyway, I also think I could set up mutable environments such that, as long as you only modify it through my tool, it could record those modifications and generate a file to recreate that environment elsewhere. That sounds like Nix, but again, my tool will use other build systems and package managers.
I tried to get into Nix recently, but found it difficult to accommodate my workflows within its uncompromising nature. My goal was to set up a reproducible development environment, where anyone at my company could easily get set up to work on our code with a single (or concise set of) action(s). I also tried to use home-manager, which I have heard might have been a mistake.
Anyway, Nix is really only designed to manage the entire world. I wasn’t able to use Nix to build a development environment where other developers and I could work inside of it using our existing tools and workflows, including other package managers that want to mutate things — it seemed that Nix was all-or-nothing. This was too disruptive and a large barrier to adoption for me.
I would love a tool designed for reproducible builds and development environments that can compromise, and do as much as possible immutably while allowing for local mutation on top. That can be a package manager, but also make it easy to use existing package managers too — with the understanding that these other package managers are typically also able to reliably reproduce a build, within their own mutable state. It’s OK if this potentially needs to mutate “the system” in the process to try to reach a goal state (e.g. installing system-wide package managers, xcode, etc.)
Nix really did not seem to be designed to allow me to use other package managers inside it like npm or cargo. It has some support for directly vending packages from those via Nix itself, but that’s not what I want right now; it’s too disruptive to my workflow. We already have all of the build reproduceability that we need via those package managers and via a container based build process. Still, a fair number of development and operational tools are required to develop the software, and I would really have liked a one-click way to set up a development environment that doesn’t require a container (which is not native on Windows or MacOS).
(I admit that it is possible that this idea fundamentally could not work for technical reasons, but it seems plausible that it could.)
Another challenge that I had was with the complexity of the Nix config and file format. It’s basically a programming language, and there isn’t always one right way to do something. That made it considerably more complicated to solve tasks that would be just a single line command if I was using e.g. Homebrew to solve the same goal (brew install xyz).
From a user experience perspective, I would like a tool that provides a simple command line porcelain for mutating the state of the environment, while tracking it immutably under the scenes, so that it’s reproducible. For example, “cmd install foo” should add the “foo” package to my environment (and rebuild it). So at the end I have a declarative description of my environment contents, but I can build that configuration using a sequence of familiar install commands.
I admire what Nix is trying to do, and see a lot of merit to the approach for defining an entire machine’s state immutably. For managing and defining the state of servers, it seems like a great idea. However, the cost to adopt it seems high, and the value would probably be marginal in our case, since we don’t need to manage servers to deploy software (instead deploying only containers); and since existing package managers provide a way to build those containers reproducibly. But containers aren't ideal for defining the tooling used by an interactive local development environment.