23 ms·

If you are looking for a language agnostic version manager, the nix package manager [0] might be worth a try. In combination with lorri [1] you will be dropped

If you are looking for a language agnostic version manager, the nix package manager [0] might be worth a try. In combination with lorri [1] you will be dropped into a shell with all required development dependencies available, when you enter the project directory. This does not only include the interpreter/compiler versions but also any other dependency you can think of, like specific libraries the project links against (well almost any, it has to be available as a nix expression, best case directly in upstream nixpkgs). For me, it has come so far that I don't have any interpreters or compilers in my main OS environment and even for one off REPL sessions, I'll use `nix shell nixpkgs#python3 -c python3`. [0]: https://nixos.org/ https://nixos.org/ [1]: https://github.com/nix-community/lorri/ https://github.com/nix-community/lorri/

xisthesqrtof9 4y ago
I know there are other comments about nix and I agree that its a pain to setup. It doesn't give you the ability to pin versions, and good luck if your dependencies are not available. But, I would encourage people to try out NixOS. Its much better than the package manager, yet it follows the same basic principles. - Uses a simple DSL language - 1 config file describes your entire environment, you basically use nix the language to tell your computer if you want wifi enabled or not, or if you want sound, or if you want i3 etc. - Its easy to roll back, since the config file is versioned (like git) I personally use a mac machine, running nixos in vmware fusion and I can't believe how long I had been using a separate machine for development and another for personal use. I get the best of both worlds with this setup; my messages and notes are here, I get world class hardware (come at me bro), and I get to control every single aspect of my development machine. I still use docker inside nixos, and yes I know its almost supposed to replace docker and all but I will get there one day, right now is not it. Areas for improvement: - They should have come up with a better name: nix, Nix and NixOS are confusing (language, package manager and operating system - in that order. Yes, they went with an upper case letter for the pkg manager) - Docs NEED to be better, this is not an easy task. The language is shared between every component. - Give playgrounds to beginners, I shouldn't have to download the minimal iso and boot it on my machine to get a sense of how powerful it is. There has to be an easier way. End of my rant. I started using it a month ago, I have run into issues with dependency pinning but I remain optimistic.
chillfox 4y ago
I have tried Nix, and am actually still using it for some simple things. But it is one of the most user hostile experiences I have had outside of some enterprise software. ASDF is significantly better when it comes to user experience.
pmarreck 4y ago
is there a reason why this couldn't just be `nix shell python3`? like "nixpkgs" is almost always the default, from what I can tell, so it could be omitted and simply be assumed to be the default, and not sure what the -c param does but perhaps it could also assume that the specified package(s) are also the ones to install/choose, in which case the whole thing could be like `nix shell -c python3`?
paskozdilar 4y ago
For those who like the concept of Nix, but don't like the Nix language, the Guix package manager [0] might also be worth a try. It's an official GNU project, inspired by Nix, and it uses Guile Scheme instead of Nix language. [0] https://guix.gnu.org/ https://guix.gnu.org/
- javajosh 4y ago
  Eventually someone will implement Nix in Javascript, and then it will explode.
  - deepsun 4y ago
    All languages get eventually implemented in Java and Javascript.
  - rgoulter 4y ago
    The code in nixpkgs does contain some code that uses relatively sophisticated programming language constructs, such as lazy evaluation, partial function application, or fixpoints. -- So I'll say there's at least some friction to Nix from the language being pure/functional. Mostly I think Nix would be just as hard if packages were expressed in any language. Stuff like "this program compiled by nix is using a different glibc than this library" is going to be confusing regardless of whether Nix expressions can be written with JavaScript; or stuff like some program assumes it can write to $HOME in its build script not playing nicely with Nix. A lot of why Nix is hard is because it's weird, and that even as an end user when things go wrong it may require understanding more about what's going on than what other solutions require.
  - Arubis 4y ago
    In both senses of the word "explode", I expect. (Tongue-in-cheek, but I'd actually like to see this happen: Nix is a fantastic concept obscured by space-alien syntax.)
  - sleepydog 4y ago
    The Guile compiler has a JavaScript frontend. You can write guix packages in JavaScript: https://lists.gnu.org/archive/html/guix-devel/2022-03/msg00174.html https://lists.gnu.org/archive/html/guix-devel/2022-03/msg001...
giancarlostoro 4y ago
I mean to try it but some of these version managers work on Windows too, I believe Nix is specific to Linux. Lorri sounds amazing though! It's the kind of thing that made me fall in love with solutions such as virtualenv (which handles the "this directory needs these specific packages" installed locally, not globally problem that Debian gives you).
- baryphonic 4y ago
  I believe Nix works on top of WSL. And IIRC, it can even handle building Windows GUI exe's, though that may be mistaken.
- vbrandl 4y ago
  One thing that differentiates nix from things like virtualenv is that each (package + version) tuple exists at most once in your local nix store and is then linked into your project environments, while virtualenv will install new copies of the packages. On the other hand you have to run the nix garbage collector to get rid of unused packages. As for Windows support: It seems to be possible to use nix in WSL [0] but I've never tried that. I have used nix alongside apt and pacman on Ubuntu/Arch before I decided to go all the way and install the NixOS distribution. Using it alongside other package managers worked really well. [0]: https://nixos.org/download.html#nix-install-windows https://nixos.org/download.html#nix-install-windows
  - mauflows 4y ago
    I've been running nix on wsl and works really well
- chriswarbo 4y ago
  > I believe Nix is specific to Linux I've used Nix on Linux (i686, x86_64 and ARM), macOS and Windows (WSL2). I believe it also works (although not officially supported) on BSDs, etc. too, although I've not tried that yet. > Lorri sounds amazing though! ...which handles the "this directory needs these specific packages" installed locally, not globally problem that Debian gives you). You're describing Nix, not Lorri. Specifically: - nix-shell provides a directory-local environments (and more, e.g. #!nix-shell to fetch script dependencies automatically) - direnv can enter/exit this nix-shell environment when cd-ing in/out of a directory - lorri makes direnv+nix-shell faster, by building the environment asynchronously in the background (rather than causing our terminal to freeze)
nvarsj 4y ago
shell.nix + nix install is _the_ killer linux dev tool imo. It replaces all the various nonsense with a hermetic, fully reproducible build environment. You can then use the same shell.nix in your CI with the nix docker image. Now you have exactly identical dev environments across CI and locally. It's awesome once you've experienced it. The biggest drawback is installing Nix on OS X is a huge pain. Docker has lots of magical UX tooling to make it rather seamless in comparison.
- mixedCase 4y ago
  Installing NixOS on modern macOS nowadays is super trivial. Copy+paste command from website, follow instructions, optionally enable flakes in a config file. That's it.
  - nvarsj 4y ago
    Oh really? Nice. I haven’t tried it myself but all my OS X colleagues complain about it.
- ris 4y ago
  > The biggest drawback is installing Nix on OS X is a huge pain Did it on an aarch64 mac the other day. One command (two?), 15 minutes, done.
acatton 4y ago
My issue with Nix is thatm like docker, it is a dumb CLI which communicate with a powerful daemon running as root. I don't understand the concept/motivation behind it, everything that nix does should be able to be done in userland, like podman does, which I love.
- viraptor 4y ago
  You can run nix without any daemon. https://nixos.org/manual/nix/stable/installation/single-user.html https://nixos.org/manual/nix/stable/installation/single-user... It's not a requirement apart from multi-user environments.
  - georgyo 4y ago
    Indeed! The daemon is not powerful at all, almost all the logic happens in the client. The client does the parsing, job ordering, and tells the daemon exactly what to do. The daemon, only required in multiuser environments, does only two things really. - ensure that the /nix/store is protected as the daemon should be the only process able to _write_ to it. Everything can read from the nix store; no nix required at all. - execute build commands in a sandbox. Providing isolation between multiple builds.
- hamandcheese 4y ago
  Because the nix store is global per system, it would be unsafe to allow any user to write to the nix store in a multi-user system. So the daemon instead mediates writes to the store. I'm not sure if there are other reasons.
- burke 4y ago
  The daemon is actually very dumb. It's just there to keep /nix/store permissions clean.
qudat 4y ago
Based on other comments like this, I gave it a try. Be prepared to sink dozens and dozens of hours learning the language, it’s features, and switching everything over. Be prepared to get stuck when you are required to use an old version of a language and things don’t install correctly — and sometimes blocked by nix itself from installing it. Be prepared to get stuck if you are not in the happy path. Be prepared to get lost in the sometimes scant documentation. I love the idea of nix, but it did not work for me except for the simplest cases.
- tra3 4y ago
  Do you think it's worth it to sink the hours up front for future efficiency gains?
  - lelanthran 4y ago
    > Do you think it's worth it to sink the hours up front for future efficiency gains? "possible future efficiency gains".
    - xpe 4y ago
      Many things in the world are possible. I often find probable to be a more useful concept than possible. Any tool with deterministic results (such as Nix) are highly likely to reduce a whole class of future problems. With this in mind, the question shifts from rather vague talk about possible futures to various kinds of scenarios. What happens when software developers have a deterministic build system? On the whole, the benefits are significant. Sure, there are costs to get there. In my view, the benefits often outweigh the costs.
      - tra3 4y ago
        Thanks for your thoughts. I worded my question poorly, I suppose, but you got my meaning. I keep seeing nix mentioned alongside complaints about it's maturity but that seems par for the course for something new, doesn't it? Until a tool reaches critical mass sharp edges are to be expected. I'll look into nix again when I have an appropriate use case.
viraptor 4y ago
One place where asdf wins in convenience is when you actually really care about versions though. It allows you to install both new and old specific versions. In nix, while you can achieve that, you'll be guided to use the currently supported major versions like python 3.8, 3.9. Making sure you build with exactly 3.7.1 as well as a module which was merged to nixpkgs later is a serious pita.
- mixedCase 4y ago
  It should not be. You're able to easily pin multiple specific nixpkg versions in a flake.
  - viraptor 4y ago
    And you can do that in theory, but in practice it ends up like this: - you want to use lang-x.y.z, so you'll just reference an old commit - turns out that version was never packaged, so you copy x.y.z-1 to your flake/overlay - you end up patching the build because it doesn't work by default with new environments - on the other hand a module you're using needs the new environment so you do your best to make everything happy - more overlaying - because you changed something crucial in a few steps, you're compiling llvm 20 times through this process and now it's 1am Compare that to putting "rust 1.59" in your .tool-version and running "asdf install". Guess who tried to use 3 specific versions of rust at the same time recently and got very familiar with the process... (That's also ignoring the issue like Ruby being packaged without the platform identifier in nix which makes it unusable for some development purposes)
    - speed_spread 4y ago
      Yup, the versions of the toolchain components required for a project to build should be specifiable at the project in an format actionable by the main build tool. Running a project should never require more than "git clone $project && $build-cmd". It should never be Nix's business (or any other OS) to provide elements of a project's toolchain. Reciprocally, projects should go out of their way to not depend on OS installed toolchain components.
norman784 4y ago
I just tried but is really a pain in macOS right now, all went smooth until I got an error while trying to install the bundler gem, I skimmed quickly GitHub and seems to be an issue of macOS and the root dir being read-only, I suppose is too much hassle to worth it, at least if you compare with docker. As others pointed, the idea behind nix is cool, but it sometimes fall short, hope it get ironed all the issues in macOS so I could give a try in the future.
- soraminazuki 4y ago
  Were you trying to install the Bundler gem as root? If that is the case, I'd recommend against it even without Nix. In any case you can find Bundler in Nixpkgs instead: nix-shell -p bundler
- Isthatablackgsd 4y ago
  Same, tried Nix on my macOS (MBA M1) back in January. The installation is painless but it ran into an issue in the first run after it. It looks like that I skipped a step somewhere, I was following the guide and it should be working but its not. I suspected it was the guide that someone forgot to include it in the documentation or edge case I experienced. Now the uninstalling part is painful because there bare minimum documentation about this. Tried all different way to remove it and I couldn't. Took me a month to finally remove Nix from my macOS, I found the information through SO.
  - LukaD 4y ago
    I had the same exact same experience. If the uninstallation wasn't such a pain in the ass I might even give nix another try in the future.
Aleksdev 4y ago
Looks cool! However it appears to have a bit of a learning curve to get up and running. Are there any other advantages to using nix?
- vbrandl 4y ago
  In the end you could use nix to build docker/VM images and use the same, reproducible environment in prod/test/CI/dev/...
- rsanheim 4y ago
  Yes! You can swoop into any thread discussing other packaging / build tools, and recommend nix, immediately sidelining any conversation about the original topic.
  - Aleksdev 4y ago
    Nice! Can’t wait to do that
- rgoulter 4y ago
  > Are there any other advantages to using nix? The advantages are more pronounced for DevOps than for developers. e.g. for DevOps, Nix allows copying a package of software (and all its dependencies) from one computer to another, with confidence that the programs will work on both machines. For developers, Nix is more appealing if you ever work on more than one computer. e.g. with Nix, it's easy to ensure you've got the same version of packages installed regardless of whether you're on macOS or Linux. It's pretty neat for side projects, in order to get "I was able to build it now, I'll be able to build it in 6 months". Whereas, if you're otherwise relying on Ubuntu's system packages, maybe the package versions got updated, and so you'll need to spend time to get your program to work with the latest compiler/libraries.
kristjansson 4y ago
Here's a use case I pose every time Nix comes up in these discussions. For $REASONS I want python 3.7.10, and the full scientific stack (numpy, scipy, pandas, numba, matplotlib, ...) at the latest compatible versions along with pytorch. I don't mind waiting for things to compile. How, if at all, can Nix help me get into an environment that meets those constraints? Can it help without requiring me to find and copy hashes of things?
- wefpijfewijefwi 4y ago
- zeec123 4y ago
  https://github.com/nix-community/poetry2nix https://github.com/nix-community/poetry2nix
- ris 4y ago
  > requiring me to find and copy hashes of things Put an incorrect hash in. Run the build. The error will tell you what hash it actually got. Copy that. Run build again.
- amelius 4y ago
  This is how I use Conda, which uses libsolv under the hood to figure out compatible versions. This makes me wonder: does Nix use libsolv, or a similar idea?
  - rgoulter 4y ago
    Nix wouldn't. Roughly, Nix's approach is to describe packages as a function of it dependencies as inputs. (And all the inputs have all their dependencies described in Nix, too). Nix doesn't do things like "install latest version of X". (One of Nix's principles is build reproducibility; the package should have the same behaviour if built with the same input). Tools like mach-nix or poetry2nix wrap around nix.. as I understand, they adapt the requirements.txt or whatever and pass it into Nix in a way that Nix can understand.
- 4y ago
gmmeyer 4y ago
I've used Nix. It solves an interesting problem. It is so complicated as to be unusable by someone who is just looking for a quick and simple solution to something like a virtual environment There's a reason why, despite being almost 20 years old, Nix has at best a small cult following. It just doesn't solve the problems that most people are looking to solve, most other solutions are simply easier and in many ways better
- Fnoord 4y ago
  Its not even 15 years old.
  - 3836293648 4y ago
    2022 - 2006 = 16
bronzecarnage 4y ago
My biggest gripe with nix is that you need sudo rights to get it running properly on another distro. I know you can do the nix-user-chroot thing, but it's not possible on machines where kernel namespaces aren't accessible for unprivileged users. I spent time understanding it, and getting it working, but it really doesn't work just universally. Once the install process becomes more like, say, miniconda -- where an unprivileged user can install it locally with ease -- nix will get a massive boost in my books. Until then, I can only yearn.
- ris 4y ago
  It is possible to use from a completely unprivileged environment by putting the nix store in your home directory instead of `/nix`. But (and it's a big but) you'll then have to build all packages from scratch because the hashes for you packages will be different to the ones in the nix binary cache.
AceJohnny2 4y ago
nix local package search sucks, and it is much more effective to use the online package search [1]. It's astounding because the local version is doing a naive, case-sensitive regex search, which is pretty bad when you're looking for, say, the Perl package MIME::Lite which can have various junctions and capitalizations. In fact, that package has a listed name of perl5.34.0-MIME-Lite but is installable as nixpkgs.perl534Packages.MIMELite!? I can't even I found the code a few months back (but can't be bothered to look it up just for a comment). I didn't fix it then because I had other priorities than learning how to modify my local copy of nix to test it. [1] https://search.nixos.org/packages https://search.nixos.org/packages
amelius 4y ago
> If you are looking for a language agnostic version manager, the nix package manager might be worth a try. Could it solve the issues we're seeing lately with NPM?

xisthesqrtof9 4y ago

I know there are other comments about nix and I agree that its a pain to setup. It doesn't give you the ability to pin versions, and good luck if your dependencies are not available. But, I would encourage people to try out NixOS. Its much better than the package manager, yet it follows the same basic principles. - Uses a simple DSL language - 1 config file describes your entire environment, you basically use nix the language to tell your computer if you want wifi enabled or not, or if you want sound, or if you want i3 etc. - Its easy to roll back, since the config file is versioned (like git) I personally use a mac machine, running nixos in vmware fusion and I can't believe how long I had been using a separate machine for development and another for personal use. I get the best of both worlds with this setup; my messages and notes are here, I get world class hardware (come at me bro), and I get to control every single aspect of my development machine. I still use docker inside nixos, and yes I know its almost supposed to replace docker and all but I will get there one day, right now is not it. Areas for improvement: - They should have come up with a better name: nix, Nix and NixOS are confusing (language, package manager and operating system - in that order. Yes, they went with an upper case letter for the pkg manager) - Docs NEED to be better, this is not an easy task. The language is shared between every component. - Give playgrounds to beginners, I shouldn't have to download the minimal iso and boot it on my machine to get a sense of how powerful it is. There has to be an easier way. End of my rant. I started using it a month ago, I have run into issues with dependency pinning but I remain optimistic.

chillfox 4y ago

I have tried Nix, and am actually still using it for some simple things. But it is one of the most user hostile experiences I have had outside of some enterprise software. ASDF is significantly better when it comes to user experience.

pmarreck 4y ago

is there a reason why this couldn't just be `nix shell python3`? like "nixpkgs" is almost always the default, from what I can tell, so it could be omitted and simply be assumed to be the default, and not sure what the -c param does but perhaps it could also assume that the specified package(s) are also the ones to install/choose, in which case the whole thing could be like `nix shell -c python3`?

paskozdilar 4y ago

For those who like the concept of Nix, but don't like the Nix language, the Guix package manager [0] might also be worth a try. It's an official GNU project, inspired by Nix, and it uses Guile Scheme instead of Nix language. [0] https://guix.gnu.org/ https://guix.gnu.org/

javajosh 4y ago
Eventually someone will implement Nix in Javascript, and then it will explode.
- deepsun 4y ago
  All languages get eventually implemented in Java and Javascript.
- rgoulter 4y ago
  The code in nixpkgs does contain some code that uses relatively sophisticated programming language constructs, such as lazy evaluation, partial function application, or fixpoints. -- So I'll say there's at least some friction to Nix from the language being pure/functional. Mostly I think Nix would be just as hard if packages were expressed in any language. Stuff like "this program compiled by nix is using a different glibc than this library" is going to be confusing regardless of whether Nix expressions can be written with JavaScript; or stuff like some program assumes it can write to $HOME in its build script not playing nicely with Nix. A lot of why Nix is hard is because it's weird, and that even as an end user when things go wrong it may require understanding more about what's going on than what other solutions require.
- Arubis 4y ago
  In both senses of the word "explode", I expect. (Tongue-in-cheek, but I'd actually like to see this happen: Nix is a fantastic concept obscured by space-alien syntax.)
- sleepydog 4y ago
  The Guile compiler has a JavaScript frontend. You can write guix packages in JavaScript: https://lists.gnu.org/archive/html/guix-devel/2022-03/msg00174.html https://lists.gnu.org/archive/html/guix-devel/2022-03/msg001...

giancarlostoro 4y ago

I mean to try it but some of these version managers work on Windows too, I believe Nix is specific to Linux. Lorri sounds amazing though! It's the kind of thing that made me fall in love with solutions such as virtualenv (which handles the "this directory needs these specific packages" installed locally, not globally problem that Debian gives you).

baryphonic 4y ago
I believe Nix works on top of WSL. And IIRC, it can even handle building Windows GUI exe's, though that may be mistaken.
vbrandl 4y ago
One thing that differentiates nix from things like virtualenv is that each (package + version) tuple exists at most once in your local nix store and is then linked into your project environments, while virtualenv will install new copies of the packages. On the other hand you have to run the nix garbage collector to get rid of unused packages. As for Windows support: It seems to be possible to use nix in WSL [0] but I've never tried that. I have used nix alongside apt and pacman on Ubuntu/Arch before I decided to go all the way and install the NixOS distribution. Using it alongside other package managers worked really well. [0]: https://nixos.org/download.html#nix-install-windows https://nixos.org/download.html#nix-install-windows
- mauflows 4y ago
  I've been running nix on wsl and works really well
chriswarbo 4y ago
> I believe Nix is specific to Linux I've used Nix on Linux (i686, x86_64 and ARM), macOS and Windows (WSL2). I believe it also works (although not officially supported) on BSDs, etc. too, although I've not tried that yet. > Lorri sounds amazing though! ...which handles the "this directory needs these specific packages" installed locally, not globally problem that Debian gives you). You're describing Nix, not Lorri. Specifically: - nix-shell provides a directory-local environments (and more, e.g. #!nix-shell to fetch script dependencies automatically) - direnv can enter/exit this nix-shell environment when cd-ing in/out of a directory - lorri makes direnv+nix-shell faster, by building the environment asynchronously in the background (rather than causing our terminal to freeze)

nvarsj 4y ago

shell.nix + nix install is _the_ killer linux dev tool imo. It replaces all the various nonsense with a hermetic, fully reproducible build environment. You can then use the same shell.nix in your CI with the nix docker image. Now you have exactly identical dev environments across CI and locally. It's awesome once you've experienced it. The biggest drawback is installing Nix on OS X is a huge pain. Docker has lots of magical UX tooling to make it rather seamless in comparison.

mixedCase 4y ago
Installing NixOS on modern macOS nowadays is super trivial. Copy+paste command from website, follow instructions, optionally enable flakes in a config file. That's it.
- nvarsj 4y ago
  Oh really? Nice. I haven’t tried it myself but all my OS X colleagues complain about it.
ris 4y ago
> The biggest drawback is installing Nix on OS X is a huge pain Did it on an aarch64 mac the other day. One command (two?), 15 minutes, done.

acatton 4y ago

My issue with Nix is thatm like docker, it is a dumb CLI which communicate with a powerful daemon running as root. I don't understand the concept/motivation behind it, everything that nix does should be able to be done in userland, like podman does, which I love.

viraptor 4y ago
You can run nix without any daemon. https://nixos.org/manual/nix/stable/installation/single-user.html https://nixos.org/manual/nix/stable/installation/single-user... It's not a requirement apart from multi-user environments.
- georgyo 4y ago
  Indeed! The daemon is not powerful at all, almost all the logic happens in the client. The client does the parsing, job ordering, and tells the daemon exactly what to do. The daemon, only required in multiuser environments, does only two things really. - ensure that the /nix/store is protected as the daemon should be the only process able to _write_ to it. Everything can read from the nix store; no nix required at all. - execute build commands in a sandbox. Providing isolation between multiple builds.
hamandcheese 4y ago
Because the nix store is global per system, it would be unsafe to allow any user to write to the nix store in a multi-user system. So the daemon instead mediates writes to the store. I'm not sure if there are other reasons.
burke 4y ago
The daemon is actually very dumb. It's just there to keep /nix/store permissions clean.

qudat 4y ago

Based on other comments like this, I gave it a try. Be prepared to sink dozens and dozens of hours learning the language, it’s features, and switching everything over. Be prepared to get stuck when you are required to use an old version of a language and things don’t install correctly — and sometimes blocked by nix itself from installing it. Be prepared to get stuck if you are not in the happy path. Be prepared to get lost in the sometimes scant documentation. I love the idea of nix, but it did not work for me except for the simplest cases.

tra3 4y ago
Do you think it's worth it to sink the hours up front for future efficiency gains?
- lelanthran 4y ago
  > Do you think it's worth it to sink the hours up front for future efficiency gains? "possible future efficiency gains".
  - xpe 4y ago
    Many things in the world are possible. I often find probable to be a more useful concept than possible. Any tool with deterministic results (such as Nix) are highly likely to reduce a whole class of future problems. With this in mind, the question shifts from rather vague talk about possible futures to various kinds of scenarios. What happens when software developers have a deterministic build system? On the whole, the benefits are significant. Sure, there are costs to get there. In my view, the benefits often outweigh the costs.
    - tra3 4y ago
      Thanks for your thoughts. I worded my question poorly, I suppose, but you got my meaning. I keep seeing nix mentioned alongside complaints about it's maturity but that seems par for the course for something new, doesn't it? Until a tool reaches critical mass sharp edges are to be expected. I'll look into nix again when I have an appropriate use case.

viraptor 4y ago

One place where asdf wins in convenience is when you actually really care about versions though. It allows you to install both new and old specific versions. In nix, while you can achieve that, you'll be guided to use the currently supported major versions like python 3.8, 3.9. Making sure you build with exactly 3.7.1 as well as a module which was merged to nixpkgs later is a serious pita.

mixedCase 4y ago
It should not be. You're able to easily pin multiple specific nixpkg versions in a flake.
- viraptor 4y ago
  And you can do that in theory, but in practice it ends up like this: - you want to use lang-x.y.z, so you'll just reference an old commit - turns out that version was never packaged, so you copy x.y.z-1 to your flake/overlay - you end up patching the build because it doesn't work by default with new environments - on the other hand a module you're using needs the new environment so you do your best to make everything happy - more overlaying - because you changed something crucial in a few steps, you're compiling llvm 20 times through this process and now it's 1am Compare that to putting "rust 1.59" in your .tool-version and running "asdf install". Guess who tried to use 3 specific versions of rust at the same time recently and got very familiar with the process... (That's also ignoring the issue like Ruby being packaged without the platform identifier in nix which makes it unusable for some development purposes)
  - speed_spread 4y ago
    Yup, the versions of the toolchain components required for a project to build should be specifiable at the project in an format actionable by the main build tool. Running a project should never require more than "git clone $project && $build-cmd". It should never be Nix's business (or any other OS) to provide elements of a project's toolchain. Reciprocally, projects should go out of their way to not depend on OS installed toolchain components.

norman784 4y ago

I just tried but is really a pain in macOS right now, all went smooth until I got an error while trying to install the bundler gem, I skimmed quickly GitHub and seems to be an issue of macOS and the root dir being read-only, I suppose is too much hassle to worth it, at least if you compare with docker. As others pointed, the idea behind nix is cool, but it sometimes fall short, hope it get ironed all the issues in macOS so I could give a try in the future.

soraminazuki 4y ago
Were you trying to install the Bundler gem as root? If that is the case, I'd recommend against it even without Nix. In any case you can find Bundler in Nixpkgs instead: nix-shell -p bundler
Isthatablackgsd 4y ago
Same, tried Nix on my macOS (MBA M1) back in January. The installation is painless but it ran into an issue in the first run after it. It looks like that I skipped a step somewhere, I was following the guide and it should be working but its not. I suspected it was the guide that someone forgot to include it in the documentation or edge case I experienced. Now the uninstalling part is painful because there bare minimum documentation about this. Tried all different way to remove it and I couldn't. Took me a month to finally remove Nix from my macOS, I found the information through SO.
- LukaD 4y ago
  I had the same exact same experience. If the uninstallation wasn't such a pain in the ass I might even give nix another try in the future.

Aleksdev 4y ago

Looks cool! However it appears to have a bit of a learning curve to get up and running. Are there any other advantages to using nix?

vbrandl 4y ago
In the end you could use nix to build docker/VM images and use the same, reproducible environment in prod/test/CI/dev/...
rsanheim 4y ago
Yes! You can swoop into any thread discussing other packaging / build tools, and recommend nix, immediately sidelining any conversation about the original topic.
- Aleksdev 4y ago
  Nice! Can’t wait to do that
rgoulter 4y ago
> Are there any other advantages to using nix? The advantages are more pronounced for DevOps than for developers. e.g. for DevOps, Nix allows copying a package of software (and all its dependencies) from one computer to another, with confidence that the programs will work on both machines. For developers, Nix is more appealing if you ever work on more than one computer. e.g. with Nix, it's easy to ensure you've got the same version of packages installed regardless of whether you're on macOS or Linux. It's pretty neat for side projects, in order to get "I was able to build it now, I'll be able to build it in 6 months". Whereas, if you're otherwise relying on Ubuntu's system packages, maybe the package versions got updated, and so you'll need to spend time to get your program to work with the latest compiler/libraries.

kristjansson 4y ago

Here's a use case I pose every time Nix comes up in these discussions. For $REASONS I want python 3.7.10, and the full scientific stack (numpy, scipy, pandas, numba, matplotlib, ...) at the latest compatible versions along with pytorch. I don't mind waiting for things to compile. How, if at all, can Nix help me get into an environment that meets those constraints? Can it help without requiring me to find and copy hashes of things?

wefpijfewijefwi 4y ago
zeec123 4y ago
https://github.com/nix-community/poetry2nix https://github.com/nix-community/poetry2nix
ris 4y ago
> requiring me to find and copy hashes of things Put an incorrect hash in. Run the build. The error will tell you what hash it actually got. Copy that. Run build again.
amelius 4y ago
This is how I use Conda, which uses libsolv under the hood to figure out compatible versions. This makes me wonder: does Nix use libsolv, or a similar idea?
- rgoulter 4y ago
  Nix wouldn't. Roughly, Nix's approach is to describe packages as a function of it dependencies as inputs. (And all the inputs have all their dependencies described in Nix, too). Nix doesn't do things like "install latest version of X". (One of Nix's principles is build reproducibility; the package should have the same behaviour if built with the same input). Tools like mach-nix or poetry2nix wrap around nix.. as I understand, they adapt the requirements.txt or whatever and pass it into Nix in a way that Nix can understand.
4y ago

gmmeyer 4y ago

I've used Nix. It solves an interesting problem. It is so complicated as to be unusable by someone who is just looking for a quick and simple solution to something like a virtual environment There's a reason why, despite being almost 20 years old, Nix has at best a small cult following. It just doesn't solve the problems that most people are looking to solve, most other solutions are simply easier and in many ways better

Fnoord 4y ago
Its not even 15 years old.
- 3836293648 4y ago
  2022 - 2006 = 16

bronzecarnage 4y ago

My biggest gripe with nix is that you need sudo rights to get it running properly on another distro. I know you can do the nix-user-chroot thing, but it's not possible on machines where kernel namespaces aren't accessible for unprivileged users. I spent time understanding it, and getting it working, but it really doesn't work just universally. Once the install process becomes more like, say, miniconda -- where an unprivileged user can install it locally with ease -- nix will get a massive boost in my books. Until then, I can only yearn.

ris 4y ago
It is possible to use from a completely unprivileged environment by putting the nix store in your home directory instead of `/nix`. But (and it's a big but) you'll then have to build all packages from scratch because the hashes for you packages will be different to the ones in the nix binary cache.

AceJohnny2 4y ago

nix local package search sucks, and it is much more effective to use the online package search [1]. It's astounding because the local version is doing a naive, case-sensitive regex search, which is pretty bad when you're looking for, say, the Perl package MIME::Lite which can have various junctions and capitalizations. In fact, that package has a listed name of perl5.34.0-MIME-Lite but is installable as nixpkgs.perl534Packages.MIMELite!? I can't even I found the code a few months back (but can't be bothered to look it up just for a comment). I didn't fix it then because I had other priorities than learning how to modify my local copy of nix to test it. [1] https://search.nixos.org/packages https://search.nixos.org/packages

amelius 4y ago

> If you are looking for a language agnostic version manager, the nix package manager might be worth a try. Could it solve the issues we're seeing lately with NPM?