Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
crane
A Nix library for building cargo projects. Never build twice thanks to incremental artifact caching.
You can get quite far without having to be aware of significant complexity.
e.g. to take a look at https://devenv.sh/ or https://www.jetpack.io/devbox/docs/installing_devbox/ which aim to leverage nix without requiring nix knowledge.
> What’s the escape hatch to bring those into the dev environment?
One thing you can do is try the Nix package manager on your Linux or macOS system. -- If it's not in nix, you can just do it the way you did things before.
If you want to try NixOS:
1. Writing a package is only necessary for sharing code.. you can still just have Python, setup a virtual env, & run the program as you would.
2. You could use a tool like Podman or Docker, to run stuff in containers. I've heard stuff like https://github.com/containers/toolbox helps this.
(Among other solutions).
As far as I know, it’s still about [0]. I’ve had a better experience with deploy-rs though [1] - or even just using nixos-rebuild to target the remote machine.
[0] - https://github.com/NixOS/nixops
I doubt your setup needed recompiling the Nix binary itself at any point. Even I did that more out of love of adventure than for any practical reasons, it’s just that the scars are still there.
And you know what, the evaluation time thing might just be a bug. Or at least I don’t see any other reason why (e.g.) `nix-shell -p yt-dlp` in my Nix-on-Droid[1] installation works reasonably fast but `nix shell nixpkgs#yt-dlp` takes minutes.
[1] https://github.com/t184256/nix-on-droid
Wanna fork:
git clone https://github.com/someuser/someproject
> I tried to install NixOS using the live cd last week in a Hyper-V VM, but it failed to get anywhere due to SquashFS errors.
Heh, that reminds me of installing NixOS back around 2014. I didn't have any way to physically boot off the install CD; so I ran it in qemu, using my real /dev/sda as the "virtual" hard drive (which I'd already partitioned). Thankfully there was no interference with the host system (Trisquel).
I'm still using (and evolved version of) the same NixOS config to this day; it still contains the following comment ( https://github.com/Warbo/nix-config/blob/master/nixos/machin... ):
trace "FIXME: Which modules are artefacts of using QEMU to install?"
I don't think it's very valid to compare the two. It is a little bit just to compare the experiences using them bit they aren't meant to solve the same set of issues. In fact, they are better together in my experience. I use nix to manage my terraform configurations with a lot of success. It reduces my boilerplate and helps me build abstractions on top of HCL.
If you ever decide to take a stab at nix again, consider looking at https://github.com/ipetkov/crane and using flakes. I've got it down to the point that I can get a new rust project set up with nix in about 30 seconds with linting, package building, and test running all in the checks