I have become one of those boring people whose first thought is “why not just use Nix” as a response to half of the technical blog posts I see. The existence of all those other projects, package managers, runtime managers, container tooling, tools for sharable reproducible development environment, much of Docker, and much more, when taken together all point to the need for Nix (and the need for Nix to reach a critical point of ease of adoption).
it doesn’t appear to support using different versions of runtimes—which is the entire point of asdf/rtx in the first place. I’m not sure why I would use devenv over homebrew if I didn’t care about versions.
Primarily the bad taste the lacking UX and documentation leaves in people’s mouths. Python development is especially crap with Nix, even if you’re using dream2nix or mach-nix or poetry2nix or whatever2nix. Technically, Nix is awesome and this is the kind of thing the Nix package manager excels at.
because the documentation is horrible, the UX is bad, and it doesn’t like it when you try to do something outside of it’s bounds. It also solves different problems from containers (well, there’s some overlap, but a networking model is not part of Nix).
I’ll adopt Nix the moment that the cure hurts less than the disease. If someone gave Nix the same UX as Rtx or Asdf, people would flock to it. Instead it has the UX of a tire fire (but with more copy-paste from people’s blogs) and a street team that mostly alienates 3/4 of the nerds who encounter it.
No, thanks for the link! This looks like a real usability improvement. I don’t know if I am in the target audience, but I could see this being very useful for reproducing env in QA.
Heh, that’s a good counterpoint. I would say, unlike with k8s I get very immediate benefits from even superficial nix use. (I do use k8s too, but only because I work with people who know it very well.) I assure you (honest) I’m not very smart. I just focus on using nix in the simplest way possible that gives me daily value, and add a little something every few months or so. I still have a long way to go!
The How it works section of the rtx README sounds very much like nix + direnv! (And of course, I’m not saying there’s no place for tools like rtx, looks like a great project!)
Nix is another solution that treats the symptoms but not the disease. I used asdf (and now rtx) mainly for Python because somehow Python devs find it acceptable to break backwards compatibility between minor versions. Therefore, some libraries define min and max supported interpreter version.
Still, I’d rather use rtx than nix. Better documentation and UX than anything Nix community created since 2003.
Yes it is difficult. Nix is great at “give me Rust” but not as great at “give me Rust 1.64.0”. That said for Rust itself there aren’t third party repos that provide such capability.
I think you are pointing out that nixpkgs tends to only ship a single version of the Rust compiler. While nixpkgs is a big component of the Nix ecosystem, Nix itself has no limitations prevent using it to install multiple version of Rust.
Obviously nix itself has no limitation as I mentioned there are other projects to enable this capability. While you are correct I was referring to nixpkgs, for all intents nixpkgs is part of the nix ecosystem. Without nixpkgs, very few people would be using or talking about nix.
What Adam means here is that depending on what revision of Nixpkgs you pull in, you will only be able to choose one version of rustc. (We only package one version of rustc, the latest stable, at any given time.)
Of course, that doesn’t stop you from mixing and matching packages from different Nixpkgs versions, they’re just… not the easiest thing to find if you want to be given a specific package version.
(Though for Rust specifically, as Adam mentioned, there are two projects that are able to do this easier: rust-overlay and Fenix.)
No I wouldn’t say so, especially using flakes. (It gets trickier if you want to use nix to pin all the libs used by a project. It’s not complicated in theory, but there are different and often multiple solutions per language.)
I just picked up rtx this week, when I noticed asdf’s shim lag adding half a second to my command prompt rendering time. Great stuff, thanks!
A question, though, since we have you here 😄 I ran into issues building Erlang on Mac M1. I don’t have the issue on asdf. Where is the right place to report the bug?
I have become one of those boring people whose first thought is “why not just use Nix” as a response to half of the technical blog posts I see. The existence of all those other projects, package managers, runtime managers, container tooling, tools for sharable reproducible development environment, much of Docker, and much more, when taken together all point to the need for Nix (and the need for Nix to reach a critical point of ease of adoption).
Well, maybe there’s a reason why nix hasn’t seen significant adoption?
The Nix community has been aware of the DX pitfalls that prevented developers to be happy with the tooling.
I’ve made https://devenv.sh to address these and make it easy for newcomers, let me know if you hit any issues.
+1 for devenv. It’s boss. The only thing I think it’s truly “missing” at the moment is package versioning (correct me if I’m wrong).
Love it! (As in: I haven’t had a reason to try it yet, but this is definitely the way to go!)
it doesn’t appear to support using different versions of runtimes—which is the entire point of asdf/rtx in the first place. I’m not sure why I would use devenv over homebrew if I didn’t care about versions.
I think the idea is a
devenvper-project, not globally, like a.tool-versionsfile; as you say, it’d be a bit of a non-sequitor otherwiseDevenv, just like Nix, support that OOTB. You simply define different shell per project.
No, it’s the children who are wrong
Primarily the bad taste the lacking UX and documentation leaves in people’s mouths. Python development is especially crap with Nix, even if you’re using dream2nix or mach-nix or poetry2nix or whatever2nix. Technically, Nix is awesome and this is the kind of thing the Nix package manager excels at.
I’ve found
mach-nix[1] very usable! I’m not primarily working with Python though.[1] https://github.com/DavHau/mach-nix
Yes, it’s way too hard to learn!
because the documentation is horrible, the UX is bad, and it doesn’t like it when you try to do something outside of it’s bounds. It also solves different problems from containers (well, there’s some overlap, but a networking model is not part of Nix).
I’ll adopt Nix the moment that the cure hurts less than the disease. If someone gave Nix the same UX as Rtx or Asdf, people would flock to it. Instead it has the UX of a tire fire (but with more copy-paste from people’s blogs) and a street team that mostly alienates 3/4 of the nerds who encounter it.
Curious did you try https://denvenv.sh yet?
https://devenv.sh for those clicking…
No, thanks for the link! This looks like a real usability improvement. I don’t know if I am in the target audience, but I could see this being very useful for reproducing env in QA.
It’s like using kubernetes. Apparently it’s great if you can figure out how to use it.
I’ve given up twice trying to use nix personally. I think it’s just for people smarter than me.
Heh, that’s a good counterpoint. I would say, unlike with k8s I get very immediate benefits from even superficial nix use. (I do use k8s too, but only because I work with people who know it very well.) I assure you (honest) I’m not very smart. I just focus on using nix in the simplest way possible that gives me daily value, and add a little something every few months or so. I still have a long way to go!
The
How it workssection of thertxREADME sounds very much like nix + direnv! (And of course, I’m not saying there’s no place for tools likertx, looks like a great project!)Nix is another solution that treats the symptoms but not the disease. I used asdf (and now rtx) mainly for Python because somehow Python devs find it acceptable to break backwards compatibility between minor versions. Therefore, some libraries define min and max supported interpreter version.
Still, I’d rather use rtx than nix. Better documentation and UX than anything Nix community created since 2003.
It’s clearly out of scope for Nix (or adf, rtx…) to fix the practices of the Python community?
Sure. It’s good that a better alternative for asdf exists, although it would be better that such a program wasn’t needed at all.
Isn’t it somewhat difficult to pin collections of different versions of software for different directories with Nix?
Yes it is difficult. Nix is great at “give me Rust” but not as great at “give me Rust 1.64.0”. That said for Rust itself there aren’t third party repos that provide such capability.
I think you meant s/aren’t/are :)
Correct. Bad typo. :)
I think you are pointing out that
nixpkgstends to only ship a single version of the Rust compiler. Whilenixpkgsis a big component of the Nix ecosystem, Nix itself has no limitations prevent using it to install multiple version of Rust.Obviously nix itself has no limitation as I mentioned there are other projects to enable this capability. While you are correct I was referring to nixpkgs, for all intents nixpkgs is part of the nix ecosystem. Without nixpkgs, very few people would be using or talking about nix.
I thought that was the point of Nix, that different packages could use their own versions of dependencies. Was I misunderstanding?
What Adam means here is that depending on what revision of Nixpkgs you pull in, you will only be able to choose one version of rustc. (We only package one version of rustc, the latest stable, at any given time.)
Of course, that doesn’t stop you from mixing and matching packages from different Nixpkgs versions, they’re just… not the easiest thing to find if you want to be given a specific package version.
(Though for Rust specifically, as Adam mentioned, there are two projects that are able to do this easier: rust-overlay and Fenix.)
This is a great tool to find a revision of Nixpkgs that has a specific version of some package that you need: https://lazamar.co.uk/nix-versions/
That said, it’s too hard, and flakes provides much nicer DX.
The original https://github.com/mozilla/nixpkgs-mozilla still works too, as far as I know. I use it, including to have multiple versions of Rust.
Alright, thanks!
No I wouldn’t say so, especially using flakes. (It gets trickier if you want to use nix to pin all the libs used by a project. It’s not complicated in theory, but there are different and often multiple solutions per language.)
Any pointers on how I can accomplish the same functionality of asdf in Nix?
Docs https://nixos.org/guides/declarative-and-reproducible-developer-environments.html or use https://devenv.sh/
These are some quick ways to get started:
Without flakes: https://nix.dev/tutorials/ad-hoc-developer-environments#ad-hoc-envs
With flakes: https://zero-to-nix.com/start/nix-develop
And add direnv to get automatic activation of environment-per-directory: https://determinate.systems/posts/nix-direnv
Or try devenv: https://devenv.sh/
(Pros: much easier to get started. Cons: very new, doesn’t yet allow you to pick all old versions of a language, for example.)
I have become one of those boring people who just downloads an installer and double clicks it.
Nice docs! Very informative
I just picked up rtx this week, when I noticed asdf’s shim lag adding half a second to my command prompt rendering time. Great stuff, thanks!
A question, though, since we have you here 😄 I ran into issues building Erlang on Mac M1. I don’t have the issue on asdf. Where is the right place to report the bug?
I just fixed that last night: https://github.com/jdxcode/rtx/issues/196
In general, file an issue on gh or send me a message on our discord.
Damn! Now that’s service. Many thanks for the fix! Now I can get asdf out of my $PATH for good 👍
This fixed it for me too!
I seamlessly switched this week on both personal and work laptops! There was an issue with Erlang but that’s now been fixed.