Maybe those are the things they feel capable of improving and they count on the second order effect of more people -> few more devs who will fix the issues?
Doubling-down on better support for nix-shell for development is smart. I think that would be a gateway drug for introducing more people to Nix.
I use darwin-nix for most of my dev environment and some simple shell.nix files for project-specific configuration. I would love to have an easy & supported way to start services from shell.nix, so I could migrate away from docker-compose to run auxiliary services my app needs; e.g. Pg, MongoDB, Redis, & RabbitMQ. (Thinking about it, I might resort to just running the services always, but using shell.nix to set up user accounts/dbs the way our apps expect.)
Every time I start Docker for Mac my Macbook Pro’s fan starts howling—we refer to this as the “Docker noise” in my company. I prefer running services natively, avoiding using Docker when I can, but the process of using nix-shell for this is not quite slick enough for me to advocate for my team to make that the preferred & default supported process. Hopefully one day!
Somewhat unrelated, I’ve had much positive feedback from changing our default process to run our Clojure service outside Docker. First and foremost the service start time is measured in double-digit seconds rather than double-digit minutes, but secondly IDE integration works so much better! I really don’t understand why people do development inside Docker. 🤷♂️
You can use the shellHook attribute in mkShell, and have it run any shell code you want. Combined with trap for the shutdown aspect and you can get pretty far. An example for Elixir/Phoenix with PostgreSQL.
I would love to have an easy & supported way to start services from shell.nix, so I could migrate away from docker-compose to run auxiliary services my app needs; e.g. Pg, MongoDB, Redis, & RabbitMQ. (Thinking about it, I might resort to just running the services always, but using shell.nix to set up user accounts/dbs the way our apps expect.)
That’s a good point and I agree that’s an area where nix needs some work.
I haven’t tried it yet, but https://github.com/svanderburg/nix-processmgmt seemed somewhat promising for offering cross-platform service definitions for a shared subset while still allowing to add platform-specific code.
I’ve definitely fallen out of the “this is awesome” period into the “too complex for the benefits” viewpoint.
Probably shown most by porting software installs out of nix back to homebrew because it’s simpler and I can keep it updated without having to experiment every time.
I’ve definitely fallen out of the “this is awesome” period into the “too complex for the benefits” viewpoint.
I understand, I went there and came back twice until it stuck (for now).
Nix and it’s ecosystem might have one of the the steepest learning curves among popular free software; I say this as an long-term Emacs and Linux user :D
And many of it’s benefits only really start to pay of when you’ve got ALL software in your nix expressions; and even then one might be tempted to endlessly hack around trying to find better abstractions. Even when you understand the language, the old cli, the new cli, stdenv and the store, common 3rd-party tooling and more, there’s still such a vast surface of things to touch.
It’s comparatively easy nowadays to bootstrap a nixos vm with nginx, lets encrypt, logging, backup and monitoring and some bells and whistles from a nix flake - and thats incredible!
But it still needs a lot of time to understand the details and ongoing maintenance of that system.
For other use cases: building oci containers and dev environments can be incredible with nix, but getting all your dependencies into nix can be quite a hassle. Especially if you use i.e. nodejs. https://github.com/nix-community/dream2nix/ does awesome work here, but it’s still in early-ish development
I just like Nix. I’m more of a high-level user. I just recently built one of my startup’s services using node2nix. Works great - and much more developer friendly than containers. I’m playing with flakes. And nixpkgs has been my preferred package manager for awhile. It’s awesome that it’s getting easier for people like me to use. I’m not involved in the community and not qualified to call the direction of nix but large institutions and corporations will pile in on this in a major way in a few years or decade. (Please nix folks don’t sell out the NixOS Foundation to Google, Meta, and Amazon: want to see the rising nix stars - updrafting nix flakes? - as the major stakeholders, along with Google and others.)
My personal hope is that people (myself included) will build more distros and even more user friendly package managers downstream from nixpkgs or NixOS for more everyday users. (And in a way that is self-funding, but not relying on licenses, Big tech sponsorship handouts or selling user data.) People won’t know they’re even using nix one day or have to understand too many details about it - things like flakes and node2nix make me really think this is the future. Nix has achieved critical mass and think it’s inevitable – congrats Nix community!
At $WORK we use Nix, and nix-shell in particular to provision reproducible environments for developers and for CI/CD pipelines. This allows anyone do just do a git clone and then make run to see the project running, and we have the assurance that this will run the same in a CI pipeline.
We also use Nix for building container images, so that we get full reproducibility and granular control over our software supply chain.
We don’t use Nix as our build system, though, for that we use Make, which I feel takes the core experience of shell scripting and adds declarative rules on top.
Reading about Bazel, it would be well suited to replace Make. Maybe there is a way for Nix to grow in this area while streamlining its features and commands?
So you use nix to ensure all dependencies are present but then let your project build “naturally”? If so, that’s sounds like an appealing approach to me. I’ve been put off using Nix because it seemed like I’d end deep down a rabbit hole reproducing build tooling that was already working.
I had something similar in the previous two companies, and it was quite a pleasant experience. There were some rough edges when upgrading Haskell dependencies, but in general it worked quite smooth.
One of the companies open-sourced the system we used back in the day: https://github.com/digital-asset/dev-env. This is a lazy-loading dev environment, where each tool would be fetched on the first use. Quite handy for monorepi, where one half uses Scala exclusively and the other half uses Haskell - neither has to wait for the tools from the other side to be downloaded.
Yes, I use Nix to provision a reproducible and auditable toolchain, but use Make for building assets and automation. We also use Nix to package assets as a reproducible container, which is quite handy.
I use nixos for most of my current and new infrastructure, but I still maintain a bunch of “legacy” promxmox machines and debian vms via an older ansible setup.
The thing includes stuff like custom plugins for secret handling, cmdb interaction and so-on and uses ansible together with mitogen. A relatively simple flake.nix uses nixpkgs, poetry2nix and a devshell with a shellhook to set up the correct python environment, the password manager, a bunch of env vars, so that a simple nix develop starts a shell with evertything needed to deploy, update and maintain that ansible setup across machines (works on nixos and debian, and worked on macOS, but we don’t use that anymore).
Yet the areas they discuss improving don’t really seem to get to the heart of this.
Maybe those are the things they feel capable of improving and they count on the second order effect of more people -> few more devs who will fix the issues?
Doubling-down on better support for
nix-shellfor development is smart. I think that would be a gateway drug for introducing more people to Nix.I use darwin-nix for most of my dev environment and some simple
shell.nixfiles for project-specific configuration. I would love to have an easy & supported way to start services fromshell.nix, so I could migrate away from docker-compose to run auxiliary services my app needs; e.g. Pg, MongoDB, Redis, & RabbitMQ. (Thinking about it, I might resort to just running the services always, but usingshell.nixto set up user accounts/dbs the way our apps expect.)Every time I start Docker for Mac my Macbook Pro’s fan starts howling—we refer to this as the “Docker noise” in my company. I prefer running services natively, avoiding using Docker when I can, but the process of using nix-shell for this is not quite slick enough for me to advocate for my team to make that the preferred & default supported process. Hopefully one day!
Somewhat unrelated, I’ve had much positive feedback from changing our default process to run our Clojure service outside Docker. First and foremost the service start time is measured in double-digit seconds rather than double-digit minutes, but secondly IDE integration works so much better! I really don’t understand why people do development inside Docker. 🤷♂️
You can use the shellHook attribute in mkShell, and have it run any shell code you want. Combined with trap for the shutdown aspect and you can get pretty far. An example for Elixir/Phoenix with PostgreSQL.
That’s a good point and I agree that’s an area where nix needs some work.
I haven’t tried it yet, but https://github.com/svanderburg/nix-processmgmt seemed somewhat promising for offering cross-platform service definitions for a shared subset while still allowing to add platform-specific code.
I’ve definitely fallen out of the “this is awesome” period into the “too complex for the benefits” viewpoint.
Probably shown most by porting software installs out of nix back to homebrew because it’s simpler and I can keep it updated without having to experiment every time.
I understand, I went there and came back twice until it stuck (for now).
Nix and it’s ecosystem might have one of the the steepest learning curves among popular free software; I say this as an long-term Emacs and Linux user :D
And many of it’s benefits only really start to pay of when you’ve got ALL software in your nix expressions; and even then one might be tempted to endlessly hack around trying to find better abstractions. Even when you understand the language, the old cli, the new cli, stdenv and the store, common 3rd-party tooling and more, there’s still such a vast surface of things to touch.
It’s comparatively easy nowadays to bootstrap a nixos vm with nginx, lets encrypt, logging, backup and monitoring and some bells and whistles from a nix flake - and thats incredible! But it still needs a lot of time to understand the details and ongoing maintenance of that system.
For other use cases: building oci containers and dev environments can be incredible with nix, but getting all your dependencies into nix can be quite a hassle. Especially if you use i.e. nodejs. https://github.com/nix-community/dream2nix/ does awesome work here, but it’s still in early-ish development
I just like Nix. I’m more of a high-level user. I just recently built one of my startup’s services using node2nix. Works great - and much more developer friendly than containers. I’m playing with flakes. And nixpkgs has been my preferred package manager for awhile. It’s awesome that it’s getting easier for people like me to use. I’m not involved in the community and not qualified to call the direction of nix but large institutions and corporations will pile in on this in a major way in a few years or decade. (Please nix folks don’t sell out the NixOS Foundation to Google, Meta, and Amazon: want to see the rising nix stars - updrafting nix flakes? - as the major stakeholders, along with Google and others.)
My personal hope is that people (myself included) will build more distros and even more user friendly package managers downstream from nixpkgs or NixOS for more everyday users. (And in a way that is self-funding, but not relying on licenses, Big tech sponsorship handouts or selling user data.) People won’t know they’re even using nix one day or have to understand too many details about it - things like flakes and node2nix make me really think this is the future. Nix has achieved critical mass and think it’s inevitable – congrats Nix community!
At $WORK we use Nix, and nix-shell in particular to provision reproducible environments for developers and for CI/CD pipelines. This allows anyone do just do a git clone and then make run to see the project running, and we have the assurance that this will run the same in a CI pipeline.
We also use Nix for building container images, so that we get full reproducibility and granular control over our software supply chain.
We don’t use Nix as our build system, though, for that we use Make, which I feel takes the core experience of shell scripting and adds declarative rules on top.
Reading about Bazel, it would be well suited to replace Make. Maybe there is a way for Nix to grow in this area while streamlining its features and commands?
So you use nix to ensure all dependencies are present but then let your project build “naturally”? If so, that’s sounds like an appealing approach to me. I’ve been put off using Nix because it seemed like I’d end deep down a rabbit hole reproducing build tooling that was already working.
I had something similar in the previous two companies, and it was quite a pleasant experience. There were some rough edges when upgrading Haskell dependencies, but in general it worked quite smooth.
One of the companies open-sourced the system we used back in the day: https://github.com/digital-asset/dev-env. This is a lazy-loading dev environment, where each tool would be fetched on the first use. Quite handy for monorepi, where one half uses Scala exclusively and the other half uses Haskell - neither has to wait for the tools from the other side to be downloaded.
Yes, I use Nix to provision a reproducible and auditable toolchain, but use Make for building assets and automation. We also use Nix to package assets as a reproducible container, which is quite handy.
I use nixos for most of my current and new infrastructure, but I still maintain a bunch of “legacy” promxmox machines and debian vms via an older ansible setup.
The thing includes stuff like custom plugins for secret handling, cmdb interaction and so-on and uses ansible together with mitogen. A relatively simple flake.nix uses nixpkgs, poetry2nix and a devshell with a shellhook to set up the correct python environment, the password manager, a bunch of env vars, so that a simple
nix developstarts a shell with evertything needed to deploy, update and maintain that ansible setup across machines (works on nixos and debian, and worked on macOS, but we don’t use that anymore).