I wanted to point something out that the series doesn't do a good job of highlighting:
You can use Nix alongside your existing package manager.
They won't conflict. You can set up dev environments with Nix without drinking the kool-aid. I still have Homebrew installed, and I still occasionally reach for it in the rare cases where Nix is missing some package I want to try. But I am sad every time I do: I never really realized how unbelievably slow Homebrew is until I tried Nix.
So if you're Nix-curious, you can try it out without committing to anything upfront. I didn't make the switch until part 19:
Nix is weird and hard to learn, but it's a lot like git in that respect. Yes, the UI is terrible. You have to learn the difference between `reset --hard` and `reset --mixed` and it's weird and unintuitive but you eventually get over it.
And people are using it despite how unintuitive it is, because of how valuable it is to them. No one is arguing that `nix-env -qaP package` is a reasonable command to ask a fellow human being to type, but people are willing to type it anyway because the benefits are worth it. As a fun example, a few weeks ago I wrote up a little hack that I would not have even attempted before spending the time to learn Nix:
I've bounced off Nix a couple of times and figured that the problem is that it was too different. A lot of Linux distros (especially post-systemd) have a fair number of similarities and it's pretty easy to translate knowledge between them. NixOS _probably_ works very similarly, but it's also got this additional declarative configuration layer on top, which is the point of using NixOS, and it's got its own special way of doing things.
You can't translate Linux knowledge to a NixOS config directly, you need NixOS' documentation to understand the "NixOS Way" of doing things, and the NixOS way of doing things does not translate into other distros. And the documentation is difficult to understand and at times seemingly arbitrary.
You have to commit to learning NixOS and understand that you are only learning NixOS, it won't help you use anything else. Other Linux distros help you learn Linux in general and inform your understanding of Linux system construction, but NixOS is its own thing. Plenty of people learn NixOS anyway, and more power to them, but it's definitely pushed me away.
> "and understand that you are only learning NixOS, it won't help you use anything else"
So — for one thing — in my personal case, it helped me at one time when I was experimenting with kernel build flags. With the caveat that finding how to change them was (surprise surprise) typically non-trivial in Nix in the first place... so it may be a feeble counterpoint... but still, after I found how to do it, NixOS made rebuilding new OS with different kernel flags absolute breeze, with basically 0 worry if I bork something (I mean, except maybe going to deep hardware params hacking such that would risk fraying some electronics) — I'd always automatically be just one GRUB entry away from a previous working configuration. (Though also useful to have `git commit`ed the previous /etc/configuration.nix from before I made some risky change, so that I could easily go tweaking again from there.)
> You have to commit to learning NixOS and understand that you are only learning NixOS, it won't help you use anything else.
This is kind of true on a surface level, but NixOS experience can be super helpful for setting up other distros because it turns Nixpkgs into a repository of high quality examples and demos that are always up to date.
Once you learn some basics of reading Nix code and how the NixOS module system works, the Nixpkgs repo itself becomes an excellent cross-distro resource on how to configure Linux software, much like the Arch and Gentoo wikis. I often consult Nixpkgs on how to do things in Linux for the purposes of configuring another distro or helping another user to do so! :)
The NixOS way of doing things (a layer on top of plain config files) is inevitable once configuration management is taken seriously: one needs to be able to merge configuration values from multiple source files; for example, a generic role plus some more machine-specific role, working together to produce one systemd unit or file in /etc. The modules in nixpkgs effectively make it possible to combine configuration values to produce most of the config files that Linux applications want.
If one weren't using NixOS to do it, it would be done with your own templates and configuration management, and probably without the huge advantage of being able to rebuild a whole immutable system without leftovers from prior configurations.
This is why I feel efforts like Fedora Silverblue might end up becoming mainstream in the years to come rather than esoteric projects like NixOS.
I personally dislike both projects though, when it comes personal desktops. Silverblue is heavily influenced by Flatpak and I don't expect RPMs for GUI applications to survive in Fedora. NixOS needs you to learn Nix which is a pretty steep learning curve and like you said, that knowledge probably won't translate anywhere else. You're probably better off investing your time learning things like shell/python scripting, Ansible, and Docker/podman.
Nix isn't a package manager, it's a system for making ad-hoc, repeatable computing environments.
The "package manager" paradigm doesn't fit Nix that well, which is why it's a painful experience when you come to it from the angle that it's another Linux distro.
(IMO it makes more sense to think of Nix as "declarative Docker that doesn't need Linux namespaces".)
The knowledge is one thing, because you can always learn how to do things the "Nix way" (either by reading the incomplete documentation or tinkering for hours until the thing works).
But the real problem is that software does not understand nix either.
For example loads of scripts expect /bin/bash to exist, but on NixOS it is missing. Want to run a random python script from github? Well that's a bummer, because there is no nix version of a random library this script uses. Also no-machine server and Chrome Remote Desktop don't work, and these are the two remote desktop solutions which work on spotty 4G.
And I had to ditch NixOS, because my employer forced me to use a proprietary VPN, and I there is no way it would run on NixOS.
> You have to commit to learning NixOS and understand that you are only learning NixOS, it won't help you use anything else.
As a NixOS user, I did learn a lot about what is part of Linux distributions and what is part of the kernel, and how they interact. Compared to my previous Ubuntu knowledge, of course. If I would have ran Arch, I would have learned similar things.
I bounced off NixOS a few times as well. In addition to what you've said, I also didn't find it compelling because I already had a way of doing programmatic configuration and functional system management under Debian using my own scripts. So I didn't particularly see what converting everything over to NixOS configs would get me.
What made NixOS stick is running up against some problems where Debian itself was ill-suited and seeing Nix's power. For example, building an image for a Raspberry Pi can be done with a handful of config lines. Changing between a cross compile and an emulated compile is also a handful of lines. This kind of power feels akin to the general lisp / functional curse where certain things become so easy they aren't even well documented because once you understand the system it's second nature.
Another benefit - I've modified kernel source and I've written my own modules, but they always fell by the wayside due to the maintenance burden of a compiling a custom kernel package. With Debian, I would end up reading kernel source plenty of times to figure out what was going on, but it was effectively read only. Whereas with NixOS, adding kernel overlays is straightforward. Using what is essentially a source distribution plays to the larger philosophy of Free software.
Same here. I still flock to the page every now and then and think about to give it yet another shot. But my main usecase is to develop software. I work with java, rust, ruby, JS and different other languages that needs custom treatment when doing things the nix way. Like writing a custom nix shell env file which deals with npm dependencies and the like to have all the glory deterministic package updates etc. I guess I will try it again at one point.
This is a pretty good take. Although I'd further emphasise: knowledge of Linux is "necessary but not sufficient" for using NixOS. NixOS requires additional knowledge, rather than a different set of knowledge.
I think for many developers with Linux experience, probably getting a reasonable NixOS desktop setup is straightforward.
There are some compelling benefits to Nix/NixOS, but these also require getting past a steep cliff in the difficulty curve.
At part 3 now, and it's great. I feel like I might finally learn what all the arcane stuff in the manuals actually mean. Most of the Nix documentation is like reading ASCII EBNF or research papers. This, on the other hand, has just the right amount of snark:
>> A store path Q is reachable from another store path P if Q is in the closure of the references relation.
>
> Good definition. Intuitive term.
One of the things I've hated about being a part-time systems administrator is the fear of the unknown. All the little changes to config files, the different installed programs, everything required to get the system working is scattered around the disk. It creates fear around making changes, because who knows which little configuration change was required to get everything working? I understand that better organizations try to combat this with rigorous processes and documentation, with great effort.
I recently evaluated NixOS for a new server deployment. Being able to describe the entire state of the system in a single file is magical - it is so clearly The Right Way to do things. I am not a Functional Programmer but using the Nix language as just a config file is fairly straightforward. I left convinced that a simple functional language is the best way to make more complex config files, way better than Jinja2 templated YAML. (Though, functionistas, come down out of the ivory tower and make a language that looks C-family. Yeah, "it's just syntax" so why not make it easy for the proles like me to learn.)
However, I ended up giving up on NixOS for two reasons.
First, while learning the basics of Nix was easy I wasn't confident about the more complex things. Packages were missing features and I was going to have to start investing in reading and writing lots of Nix code. I couldn't continue ignoring the many intricacies of the Nix system if I wanted to be confident that I could quickly fix an issue at 2AM on a Saturday. As others have noted, there is a lack of good intermediate-level documentation apart from this great "How to Learn Nix" blog. My whole interest in Nix was being able to completely document the system so that future me or someone else could quickly understand how the system is configured. That doesn't work if you can't count on that person knowing Nix very well. Even if I invested in learning Nix it would feel like professional malpractice to dump some heavily customized Nix system on the next guy to come along.
Second, there's no LTS. That's fine if it's a dev machine, or if you have a professional full-time ops team watching package changelogs and testing upgrades. My machines need to survive with bare-minimum supervision.
I learned Nix a couple days ago because I needed a build system for my project that could handle many different tools: Java+Gradle, Thrift, Rust, Python, CUDA, etc.
It's been kind of a pain: Docker is easier to get started with. But the payoff seems higher because it does handle all these tools in a sensible way: For development I can switch between subprojects written in many different languages and get the exact Python, Java, etc. and all necessary libraries are in scope.
I've gotten it working on Linux, and I expect a little more work porting to Mac OS for teammates(mostly for things like switching from CUDA to CPU based on system), but using it should be similar to Linux. Mac doesn't support cgroups or Linux containers so sandboxing is weaker than Linux, so it's better to develop Nix projects on Linux and add other platforms afterward.
I would recommend it for polyglot or Python projects. But for single-language projects with a sensible dependency manager(Rust Cargo), there's not as much benefit.
Nix is really nice for polyglot development environments on macOS, because the fact that Docker requires full machine virtualization makes it very heavyweight. Nix gets to be a lot faster and simpler. (And you can use it to generate Docker images and full fat VMs if you still want that option.)
I've tried to learn nix and tried to read various documentation. The problem was that there was always a piece of information missing. That was until I've found the nix pills which are a pretty good and structured introduction on people interested in building packages with nix.
From the start this looks very promising from more than one angle, including as an ux review done by an actual user:
> If someone who contributes to Nix ever actually sees these blog posts, I hope that they take them for what they are: a weird kind of user acceptance test. Not demands or complaints, just the story of one person’s experience.
I've been looking for a simple package management solution that doesn't interfere with my OS and simply puts all packages in /some_location/package/version, and that allows me to install packages on remote machines together with the other packages they depend on.
I thought Nix could be this; unfortunately it looks like it's an overengineered thing that requires that everything you do follows the Nix philosophy.
Does anyone else not use any of the ad hoc package management with Nix? I exclusively use a declarative `config.nix`, with `sudo nixos-rebuild switch` every time I want to install a package.
I extensively use nix-shell if that falls under ad-hoc package management. Together with lorri[0], I can place a `shell.nix` in my project repository and when cd'ing into the folder, I will be dropped in a shell with all project specific dependencies available to me.
This is what I do. If I need an ad hoc environment, I use `nix shell`, or I set up a flake for the project and have `direnv` activate it when I `cd` into the project directory or open the folder in VS Code.
> Okay! Wow. The script is 1338 lines long. That’s a lotta shell – I will not reproduce it here. But also: come on, Nix maintainers. Trim one line. You’re so close.
Made me laugh! :D
This material is gold by the way - I am learning NixOS and HomeManager myself, and a lot of questions I also have are addressed here. Thanks a lot!
NixOS claims to be "reproducible", "declarative" and "reliable".
Yet there is no way of "declaring" which version of given package you want to install, which might be seen as hard requirement for some build to be "reproducible". You might need to stick to some old (but tested) version when building "reliable" system.
> Yet there is no way of "declaring" which version of given package you want to install
But there is? First, by pinning nixpkgs you pin to whatever set of versions was within nixpkgs at the time. Then, if you want to change the version of a package, you can use overlays to poke at what source version is being used to build a package (or what flags it's being built with, etc). There's also nothing preventing your from mixing derivations from multiple nixpkgs pins within a single nixpkgs/nixos fixpoint for your system.
Stuff that in your shell.nix or /etc/nixos/configuration.nix or just nix-build it straight from a small .nix file.
Indeed, when you depend on a package from a Nix channel, you implicitly depend always on the latest definition of that package in that channel.
When the version matters, Nix has separate packages for separate versions. There are separate Nix packages for Python 2.7, 3.7, 3.8, 3.9 or 3.10, and there's OpenJDK 8, 11 and 17, etc.
You probably don't want to depend on an overly specific version anyway. If a security fix for one of your dependencies is released, you want it. Furthermore, CI ensures that everything within a channel is maximally consistent.
You can use nix-shell to create complete runtime environments with pinned software versions. Not sure re nix flakes (it's been a while since I last used Nix) however I found nix-shell pretty good for exactly this type of stuff.
Ok so I have 0 experience with Nix however, I been eyeballing it for some time now. I like the setup of this post, but I run my personal infra completely from code (docker compose, traefic). I now run this on Ubuntu and I’ve been wondering for some time why my infra can be declarative but my OS can’t. And then I started eyeballing NixOS…
I think from my perspective it wil make more sense i.e. the first thing that OP runs into is:
“ nix-env -i git, right? Wrong. I mean, you could do that. But you actually want to say nix-env -iA nixpkgs.git. Why? Don’t worry about it.”
My Nix-noob but declarative mindset would assume the "A" is to add the install somewhere to a file needed to recreate the server at some point. Am I wrong? No idea… Actually, I already find it strand that you can call the package manager like that, shouldn't there be a declaration of the packages I want somewhere, should I not add the package that list (maybe a Yaml, like my docker-compose.yaml?) then ask Nix to make the installation consistent with the declaration?
> Actually, I already find it strand that you can call the package manager like that, shouldn't there be a declaration of the packages I want somewhere, should I not add the package that list (maybe a Yaml, like my docker-compose.yaml?) then ask Nix to make the installation consistent with the declaration?
Yes, I completely avoid 'nix-env' for that reason. It maintains a bunch of symlinks behind-the-scenes, but the 'nix-env' command itself is imperative.
If you use NixOS, the config option 'env.systemPackages' specifies which programs to install. This can be declared in the /etc/nixos/configuration.nix file. There are similar approaches when using Nix on non-NixOS systems (e.g. using the 'buildEnv' function from Nixpkgs to combine multiple programs into a single derivation/package, and install that)
The "-A" shortflag indicates that the argument given is an "attribute path".
Roughly: without the "-A", the command searches for packages named "git" and installs that. With the "-A", it will install the "git" package from nixpkgs.
The name is actually referencing nix in latin, which means snow. That’s also why the logo. But even better is “nix flakes”, which just takes the name to a completely different level.
Part 41 is basically what made me realize Nix wasn't ready to use yet. In addition to a number of smaller things.
Overall, I'm still on the fence about having to rewrite all the configuration files and documentation in Nix, but having a unified setup is enticing. Maybe there's a way documentation can we prevesred and translated automatically, but it seems difficult to me.
Excellent blog series! Very good reading for people who've been using Nix for a long time, because it gives you a clear sense of things you've likely forgotten by now
[+] [-] ianthehenry|4 years ago|reply
I wanted to point something out that the series doesn't do a good job of highlighting:
You can use Nix alongside your existing package manager.
They won't conflict. You can set up dev environments with Nix without drinking the kool-aid. I still have Homebrew installed, and I still occasionally reach for it in the rare cases where Nix is missing some package I want to try. But I am sad every time I do: I never really realized how unbelievably slow Homebrew is until I tried Nix.
So if you're Nix-curious, you can try it out without committing to anything upfront. I didn't make the switch until part 19:
https://ianthehenry.com/posts/how-to-learn-nix/switching-fro...
Nix is weird and hard to learn, but it's a lot like git in that respect. Yes, the UI is terrible. You have to learn the difference between `reset --hard` and `reset --mixed` and it's weird and unintuitive but you eventually get over it.
And people are using it despite how unintuitive it is, because of how valuable it is to them. No one is arguing that `nix-env -qaP package` is a reasonable command to ask a fellow human being to type, but people are willing to type it anyway because the benefits are worth it. As a fun example, a few weeks ago I wrote up a little hack that I would not have even attempted before spending the time to learn Nix:
https://ianthehenry.com/posts/janet-game/how-to-patch-emacs/
[+] [-] indigo747|4 years ago|reply
You can't translate Linux knowledge to a NixOS config directly, you need NixOS' documentation to understand the "NixOS Way" of doing things, and the NixOS way of doing things does not translate into other distros. And the documentation is difficult to understand and at times seemingly arbitrary.
You have to commit to learning NixOS and understand that you are only learning NixOS, it won't help you use anything else. Other Linux distros help you learn Linux in general and inform your understanding of Linux system construction, but NixOS is its own thing. Plenty of people learn NixOS anyway, and more power to them, but it's definitely pushed me away.
[+] [-] akavel|4 years ago|reply
So — for one thing — in my personal case, it helped me at one time when I was experimenting with kernel build flags. With the caveat that finding how to change them was (surprise surprise) typically non-trivial in Nix in the first place... so it may be a feeble counterpoint... but still, after I found how to do it, NixOS made rebuilding new OS with different kernel flags absolute breeze, with basically 0 worry if I bork something (I mean, except maybe going to deep hardware params hacking such that would risk fraying some electronics) — I'd always automatically be just one GRUB entry away from a previous working configuration. (Though also useful to have `git commit`ed the previous /etc/configuration.nix from before I made some risky change, so that I could easily go tweaking again from there.)
[+] [-] pxc|4 years ago|reply
This is kind of true on a surface level, but NixOS experience can be super helpful for setting up other distros because it turns Nixpkgs into a repository of high quality examples and demos that are always up to date.
Once you learn some basics of reading Nix code and how the NixOS module system works, the Nixpkgs repo itself becomes an excellent cross-distro resource on how to configure Linux software, much like the Arch and Gentoo wikis. I often consult Nixpkgs on how to do things in Linux for the purposes of configuring another distro or helping another user to do so! :)
[+] [-] ivank|4 years ago|reply
If one weren't using NixOS to do it, it would be done with your own templates and configuration management, and probably without the huge advantage of being able to rebuild a whole immutable system without leftovers from prior configurations.
[+] [-] _2paq|4 years ago|reply
I personally dislike both projects though, when it comes personal desktops. Silverblue is heavily influenced by Flatpak and I don't expect RPMs for GUI applications to survive in Fedora. NixOS needs you to learn Nix which is a pretty steep learning curve and like you said, that knowledge probably won't translate anywhere else. You're probably better off investing your time learning things like shell/python scripting, Ansible, and Docker/podman.
[+] [-] otabdeveloper4|4 years ago|reply
The "package manager" paradigm doesn't fit Nix that well, which is why it's a painful experience when you come to it from the angle that it's another Linux distro.
(IMO it makes more sense to think of Nix as "declarative Docker that doesn't need Linux namespaces".)
[+] [-] alufers|4 years ago|reply
But the real problem is that software does not understand nix either.
For example loads of scripts expect /bin/bash to exist, but on NixOS it is missing. Want to run a random python script from github? Well that's a bummer, because there is no nix version of a random library this script uses. Also no-machine server and Chrome Remote Desktop don't work, and these are the two remote desktop solutions which work on spotty 4G.
And I had to ditch NixOS, because my employer forced me to use a proprietary VPN, and I there is no way it would run on NixOS.
[+] [-] huijzer|4 years ago|reply
As a NixOS user, I did learn a lot about what is part of Linux distributions and what is part of the kernel, and how they interact. Compared to my previous Ubuntu knowledge, of course. If I would have ran Arch, I would have learned similar things.
[+] [-] mindslight|4 years ago|reply
What made NixOS stick is running up against some problems where Debian itself was ill-suited and seeing Nix's power. For example, building an image for a Raspberry Pi can be done with a handful of config lines. Changing between a cross compile and an emulated compile is also a handful of lines. This kind of power feels akin to the general lisp / functional curse where certain things become so easy they aren't even well documented because once you understand the system it's second nature.
Another benefit - I've modified kernel source and I've written my own modules, but they always fell by the wayside due to the maintenance burden of a compiling a custom kernel package. With Debian, I would end up reading kernel source plenty of times to figure out what was going on, but it was effectively read only. Whereas with NixOS, adding kernel overlays is straightforward. Using what is essentially a source distribution plays to the larger philosophy of Free software.
[+] [-] larusso|4 years ago|reply
[+] [-] rgoulter|4 years ago|reply
I think for many developers with Linux experience, probably getting a reasonable NixOS desktop setup is straightforward.
There are some compelling benefits to Nix/NixOS, but these also require getting past a steep cliff in the difficulty curve.
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] domenkozar|4 years ago|reply
I've started https://nix.dev about a year ago to provide a resource for newcomers.
I'm working on comprehensive language tutorial next, but I'm mostly interested what you'd like to learn when getting started.
[+] [-] l0b0|4 years ago|reply
[+] [-] mastax|4 years ago|reply
I recently evaluated NixOS for a new server deployment. Being able to describe the entire state of the system in a single file is magical - it is so clearly The Right Way to do things. I am not a Functional Programmer but using the Nix language as just a config file is fairly straightforward. I left convinced that a simple functional language is the best way to make more complex config files, way better than Jinja2 templated YAML. (Though, functionistas, come down out of the ivory tower and make a language that looks C-family. Yeah, "it's just syntax" so why not make it easy for the proles like me to learn.)
However, I ended up giving up on NixOS for two reasons.
First, while learning the basics of Nix was easy I wasn't confident about the more complex things. Packages were missing features and I was going to have to start investing in reading and writing lots of Nix code. I couldn't continue ignoring the many intricacies of the Nix system if I wanted to be confident that I could quickly fix an issue at 2AM on a Saturday. As others have noted, there is a lack of good intermediate-level documentation apart from this great "How to Learn Nix" blog. My whole interest in Nix was being able to completely document the system so that future me or someone else could quickly understand how the system is configured. That doesn't work if you can't count on that person knowing Nix very well. Even if I invested in learning Nix it would feel like professional malpractice to dump some heavily customized Nix system on the next guy to come along.
Second, there's no LTS. That's fine if it's a dev machine, or if you have a professional full-time ops team watching package changelogs and testing upgrades. My machines need to survive with bare-minimum supervision.
[+] [-] MichaelBurge|4 years ago|reply
It's been kind of a pain: Docker is easier to get started with. But the payoff seems higher because it does handle all these tools in a sensible way: For development I can switch between subprojects written in many different languages and get the exact Python, Java, etc. and all necessary libraries are in scope.
I've gotten it working on Linux, and I expect a little more work porting to Mac OS for teammates(mostly for things like switching from CUDA to CPU based on system), but using it should be similar to Linux. Mac doesn't support cgroups or Linux containers so sandboxing is weaker than Linux, so it's better to develop Nix projects on Linux and add other platforms afterward.
I would recommend it for polyglot or Python projects. But for single-language projects with a sensible dependency manager(Rust Cargo), there's not as much benefit.
[+] [-] pxc|4 years ago|reply
[+] [-] eternauta3k|4 years ago|reply
[+] [-] eulenteufel|4 years ago|reply
[+] [-] domenkozar|4 years ago|reply
[+] [-] skinkestek|4 years ago|reply
> If someone who contributes to Nix ever actually sees these blog posts, I hope that they take them for what they are: a weird kind of user acceptance test. Not demands or complaints, just the story of one person’s experience.
[+] [-] mgaunard|4 years ago|reply
I thought Nix could be this; unfortunately it looks like it's an overengineered thing that requires that everything you do follows the Nix philosophy.
[+] [-] enricozb|4 years ago|reply
[+] [-] Throwaway194902|4 years ago|reply
[0]: https://github.com/nix-community/lorri
[+] [-] kenada|4 years ago|reply
[+] [-] 3np|4 years ago|reply
Do you find it works well for you?
I think that a lot of my pain points with Nix comes from not “doing things the Nix way”.
[+] [-] mason55|4 years ago|reply
[+] [-] spindle|4 years ago|reply
[+] [-] fowlie|4 years ago|reply
Made me laugh! :D
This material is gold by the way - I am learning NixOS and HomeManager myself, and a lot of questions I also have are addressed here. Thanks a lot!
[+] [-] harvie|4 years ago|reply
[+] [-] q3k|4 years ago|reply
But there is? First, by pinning nixpkgs you pin to whatever set of versions was within nixpkgs at the time. Then, if you want to change the version of a package, you can use overlays to poke at what source version is being used to build a package (or what flags it's being built with, etc). There's also nothing preventing your from mixing derivations from multiple nixpkgs pins within a single nixpkgs/nixos fixpoint for your system.
Stuff that in your shell.nix or /etc/nixos/configuration.nix or just nix-build it straight from a small .nix file.
[+] [-] zwiek|4 years ago|reply
When the version matters, Nix has separate packages for separate versions. There are separate Nix packages for Python 2.7, 3.7, 3.8, 3.9 or 3.10, and there's OpenJDK 8, 11 and 17, etc.
You probably don't want to depend on an overly specific version anyway. If a security fix for one of your dependencies is released, you want it. Furthermore, CI ensures that everything within a channel is maximally consistent.
[+] [-] ducktective|4 years ago|reply
https://news.ycombinator.com/item?id=28591661
[+] [-] seniorivn|4 years ago|reply
[+] [-] jskrablin|4 years ago|reply
[+] [-] teekert|4 years ago|reply
I think from my perspective it wil make more sense i.e. the first thing that OP runs into is:
“ nix-env -i git, right? Wrong. I mean, you could do that. But you actually want to say nix-env -iA nixpkgs.git. Why? Don’t worry about it.”
My Nix-noob but declarative mindset would assume the "A" is to add the install somewhere to a file needed to recreate the server at some point. Am I wrong? No idea… Actually, I already find it strand that you can call the package manager like that, shouldn't there be a declaration of the packages I want somewhere, should I not add the package that list (maybe a Yaml, like my docker-compose.yaml?) then ask Nix to make the installation consistent with the declaration?
[+] [-] chriswarbo|4 years ago|reply
Yes, I completely avoid 'nix-env' for that reason. It maintains a bunch of symlinks behind-the-scenes, but the 'nix-env' command itself is imperative.
If you use NixOS, the config option 'env.systemPackages' specifies which programs to install. This can be declared in the /etc/nixos/configuration.nix file. There are similar approaches when using Nix on non-NixOS systems (e.g. using the 'buildEnv' function from Nixpkgs to combine multiple programs into a single derivation/package, and install that)
[+] [-] rgoulter|4 years ago|reply
The "-A" shortflag indicates that the argument given is an "attribute path".
Roughly: without the "-A", the command searches for packages named "git" and installs that. With the "-A", it will install the "git" package from nixpkgs.
[+] [-] Abimelex|4 years ago|reply
[+] [-] lom|4 years ago|reply
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] nixpulvis|4 years ago|reply
Overall, I'm still on the fence about having to rewrite all the configuration files and documentation in Nix, but having a unified setup is enticing. Maybe there's a way documentation can we prevesred and translated automatically, but it seems difficult to me.
[+] [-] k__|4 years ago|reply
Next, I read about the concepts and tried to map them to Git in my mind.
In the end I had the impression that Nix is a cleaner, more general PyEnv.
[+] [-] zuj|4 years ago|reply
[+] [-] pxc|4 years ago|reply