14 ms·

I love the idea of nix but the inconsistency and developer experience is terrible. I want to suggest people use it but there is too many rough edges currently

by sontek 5y ago

I love the idea of nix but the inconsistency and developer experience is terrible. I want to suggest people use it but there is too many rough edges currently. For example, if you want to install a package the old way, you'll install it including the channel: nix-env -iA nixpkgs.ripgrep but then if you want to remove one, you don't reference the channel: nix-env -e ripgrep You have a similar issue if you want to use the new `nix` command. To install a package you'll do: nix profile install nixpkgs#ripgrep but running: nix profile remove nixpkgs#ripgrep will do nothing. It won't say "I didn't remove the package" or "package not found". It just returns silently. The only way to remove it is to point to the number from `nix profile history` or the actual path. It is unbearably slow: > time nix-env -qaP ripgrep nixpkgs.ripgrep ripgrep-13.0.0 11.17s user 2.70s system 73% cpu 18.970 total Overall I love the idea but it has a long way to go in developer experience and quality before it is ready for any mainstream adoption.

Izkata 5y ago
It's the "-A" that requires "nixpkgs." for installing. It's slower and probably there's other details I'm missing (the complexity rarely makes me want to dig deeper than these bare-basic nix-env commands since I only use it for a couple of things), but you can do "nix-env -i ripgrep".
- soraminazuki 5y ago
  Actually, -A makes it faster and more precise about what you want to install. The Nixpkgs repository is defined as large associative array containing packages. When "-A nixpkgs.ripgrep" is specified, nix-env looks up the associative array using the key "ripgrep". That in theory should take constant time regardless of the size of Nixpkgs. When -A isn't specified, nix-env searches the entire associative array for a package whose "name" attribute looks similar to "ripgrep." That takes more time as the size of Nixpkgs grows. It's also less precise because the "name" attribute for packages aren't guaranteed to be unique, unlike a key for an associative array. It doesn't do an exact match either, because the "name" attribute also includes version numbers by convention. For uninstalling, nix-env doesn't have the -A flag, because it has to operate on the set of installed packages, not Nixpkgs.
  - jeddy3 5y ago
    Yeah, thats what he is saying as well, the long parenthesis makes it kinda hard to parse, but you are saying the same thing.
bogota 5y ago
This has been my experience as well. I have wanted so badly to love it and try and introduce it into many different systems to provide consistent tooling but its just too slow. I also found that many people had a hard time picking it up myself included.
chrisweekly 5y ago
Thank you sincerely for this public service announcement. We might joke about getting "nerd-sniped", but it really can be difficult to predict ROI when choosing which new things merit attention. This glimpse into real DX issues probably saved me (and many others) some real time and frustration. OTOH I want to encourage those who do have the time and inclination to get involved and improve those things and help reify the good ideas / fulfill their potential.
- _huayra_ 5y ago
  I really wanted to love Nix and tried my best to ease into it, e.g. using it as a "pip" replacement for Python, then managing dotfiles, etc. Maybe I chose the wrong side of the "flakes schism", but it was so foggy and unclear how one went from "lazily evaluated attribute set" to "an actual system". I really wish this was written in something even like Haskell or Ocaml, that has actual real language support and tooling. Troubleshooting attribute errors was just not possible and I gave up (GUIX looks awesome, but I can't really use shepherd unfortunately). It really says something when I found myself looking to Gentoo as an "easier, well-thought-out alternative"...
  - carlmr 5y ago
    >I really wish this was written in something even like Haskell or Ocaml, that has actual real language support and tooling. Troubleshooting attribute errors was just not possible and I gave up (GUIX looks awesome, but I can't really use shepherd unfortunately). The 3 times I've tried to use Nix (and invariably gave up), I always came to this conclusion. A language like F#/OCaml with great typing and type inference and good auto completion could get us half the way to usability.
    - Smaug123 5y ago
      Nickel Is Coming! https://github.com/tweag/nickel https://github.com/tweag/nickel, e.g. https://github.com/tweag/nickel/blob/master/examples/polymorphism/polymorphism.ncl https://github.com/tweag/nickel/blob/master/examples/polymor... . Looks really exciting to me!
soraminazuki 5y ago
For installing a package, you have to specify the package repository. For uninstalling, you don't because you're operating against a separate repository containing locally installed packages. This should be the same for the new CLI too. Looking at the manual[1], instead of: nix profile remove nixpkgs#ripgrep You'd probably need to run: nix profile remove packages.x86_64-linux.ripgrep For searching packages, nix search nixpkgs ripgrep is faster than nix-env -qaP ripgrep But I find the online search UI[2] to be far more superior. [1]: https://nixos.org/manual/nix/unstable/command-ref/new-cli/nix3-profile-remove.html https://nixos.org/manual/nix/unstable/command-ref/new-cli/ni... [2]: https://search.nixos.org/packages https://search.nixos.org/packages
- brongondwana 5y ago
  This sounds like an unpleasant UX. Am not compelled to try.
  - soraminazuki 5y ago
    If Nix was about replacing apt's CLI syntax, then sure. But its promises are more than that.
    - brongondwana 5y ago
      Is there any data on how many people care about said promises as opposed to care about not having an actively hostile and prickly interface? Because I enjoyed tinkering with this kind of thing in my 20s, but in my 40s I just want something that I can use without having to memorize a ton of arcania, and that lets me solve my problem and get back to my actual goals. I never wake up saying "today I want to install a package on my computer and revel in my extreme knowledge of how my package manager works". I wake up with plans, and installing a package might be necessary to achieve them.
      - soraminazuki 5y ago
        To be clear, Nix's CLI syntax is what it is because of the following requirements: * Provide the ability to create a new package by extending an existing package definition programatically * Provide the ability to have multiple variations of similar packages To satisfy those requirements, you need a way to uniquely specify packages by its precise location of its definition. It does not interact well with apt's model of having a central package repository assign names for every known package. > "today I want to install a package on my computer and revel in my extreme knowledge of how my package manager works" Was this straw man mockery really necessary?`
Jaepa 5y ago
I'm going to preempt this with anything not explicitly forbidden is allowed, lest this come off as "you holding it wrong". Using the CLI to add/remove package is considered kind of an antipattern in nix. The correct way to write a fair bit of Nix (the language) to install and configure things. That then can be versioned, forked, etc. There are a lot of really cool parts of Nix, but they're under a ball of rough edges.
- sontek 5y ago
  Yeah, the hard part is maintaining a file just to have the tools you want is a major hurdle that is not reasonable for most people to jump over. If I'm working I might do something like this: curl example.com/data.json | jq ... and I'll realize I don't have `jq` installed. I do not want to open vim, edit a configuration file, and then re-run a command to rebuild my system. I just want jq. I can't change context like that just to get a package. I understand this isn't aligned with the purity stance that nix has but if they were able to allow this use case, it would most likely get more people doing it the right way eventually. I can't drink all the kool-aid at once, I really need to replace bits of my workflow at a time and I can't do that with nix currently. The approach I've laid out in my original comment (using `nix-env`) provides a bad developer experience and makes me not able(willing?) to move forward with the adopting more of the practices. If the initial experience was better, I'd invest more time learning more.
  - Jaepa 5y ago
    Oh I don't disagree. The onboarding experience is terrible. * You have to learn a new and kind of knobbly single use language. * If you are going the NixOS route there's the non-trival learning curve for that as well. * And the package manager itself is more than a little confusing. As for the workflow. I use NixOS on my personal machine. I'm fine with it because its typically pretty quick and happens infrequently. Buuuuuuut I wouldn't really advocate for NixOS. Its cool. I like it. I'm never going to recoop the time and effort I spent learning how to use it.
  - ayushnix 5y ago
    > Yeah, the hard part is maintaining a file just to have the tools you want I'd be okay doing that to install packages but what I don't like is the N number of ways to install packages. Do I use nix-env? Do I use the new nix CLI? Do I make an entry in configuration.nix? Do I use this thing called flakes which is marked as experimental but almost everyone seems to be onboard with it? There's no central and definitive source of documentation either. There's the official NixOS website, nix pills, nixos.wiki, blog posts from prominent developers, and other sources I don't remember. Seems like a fragmented mess to me.
MarcScott 5y ago
This is probably because I'm on NixOS but I have never used nix-env to install anything. I use nix-shell to test out a package, or use one that I only need temporarily. If I need a package for a particular build then it gets added to my config files, and I rebuild switch. If I don't want that package anymore, then I remove it from my config and do another rebuild. I've never really understood the use case for nix-env.
- huijzer 5y ago
  I once spend 2 hours on trying to get a newer version of nodejs on my system. Turned out that I had used nix-env a while back to install it and that had priority over the rebuild-switch :| So, I agree. Very risky way of managing nix
  - kreetx 5y ago
    nix-env has been easier to use for a new use compared to having a configuration.nix, using home-manager etc, but once you start using any of the latter then just remove everything installed with nix-env (and use nix-shell for one-offs).
    - _andrei_ 5y ago
      nix-env -e "*" # remove all packages
- iamevn 5y ago
  for those one-off times I want to just jump into a shell with, say, ranger available, it's as simple as $ nix shell nixpkgs#ranger if I am starting up a project that needs a tool, I just throw together a simple shell.nix in a folder for the project and run $ nix shell from that folder. there's ways to set it up so you automatically switch to a shell with the specified packages (iirc with direnv just like you'd do it for python venvs) but I haven't felt the need yet. https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3-shell.html https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3... https://nixos.wiki/wiki/Development_environment_with_nix-shell https://nixos.wiki/wiki/Development_environment_with_nix-she...
colordrops 5y ago
It's unfortunate that this is the top comment, as it might unfairly turn potential users off to Nix. Imperative command line installation of packages with nix is contrary the model of how it is supposed to work, and is deprecated. I've never used it once.
- GlennS 5y ago
  Is that documented anywhere? I've been using Nix for about 6 years now, and have mostly been using `nix-env -iA`, `nix-env -qaP --description` and `nix-env -e` the whole time.
  - colordrops 5y ago
    I'm much newer user and admittedly the documentation is not great, so I've used forums and IRC a lot and from what I've gathered, the movement is towards declarative reproduceability. This is the reason for the development of flakes. I saw installation of packages using nix-env in many search results and tutorial pages but newer comments seem to indicate that this is no longer recommended, and it fully makes sense to me. I want to get my machine back to the same state using my config checked into git, and installing imperatively using nix-env clearly goes against this.
  - rgoulter 5y ago
    > I've been using Nix for about 6 years now, and have mostly been using `nix-env -iA`, `nix-env -qaP --description` and `nix-env -e` the whole time. I'd suggest "declarative package management" as a level-up above this. https://nixos.org/manual/nixpkgs/stable/#sec-declarative-package-management https://nixos.org/manual/nixpkgs/stable/#sec-declarative-pac...
    - GlennS 5y ago
      Thanks very much!
- PoignardAzur 5y ago
  The thing is, it might be contrary to the underlying model of the OS, but it's how a lot of people want to do it. To give a similar example: in the Rust programming language, dependencies are declared in a TOML file. While the dependencies are declarative, there's also a popular tool (that's being added to the main project) that lets you do cargo add awesome-thing-rs and add the dependency to your project, and edits the config file for you. That's it: no combinations to remember, no weird use cases, no unintuitive error messages, you just say "I want to add X" and then X is added. I don't see why Nix couldn't do the same.
mongol 5y ago
I just started to install nix and my first impression is the opposite of terrible. The way it describes what it will do in detail, before doing it, I think is _excellent_. Of course, I have not started using nix yet but to me this shows some attention to detail that developers appreciate and that most other tools don't bother with. I am hopeful I will like it.
- Smaug123 5y ago
  The installer is absolutely first rate, but I would strongly recommend asking for help at discourse.nixos.org as soon as you start getting stuck (which will definitely happen, probably rather early).
- throwamon 5y ago
  Funny you say that, because the installer is about the only thing that is helpful like that. Everything else from there is basically "what do you mean you didn't read the entirety of the official manual, and the deprecated wiki, and the unofficial wiki, and the other wiki, and Discourse, and IRC, and random blog posts, and just learn to read undocumented inconsistent idiosyncratic source code already!?" They do help you really quick on Matrix though.
otabdeveloper4 5y ago
Nix doesn't install packages. Nix is just an isolation and sandboxing system for build artefacts. NixOs can install packages, but it doesn't use nix-env.
tomberek 5y ago
profile removal: Fixed in https://github.com/NixOS/nix/pull/6086 https://github.com/NixOS/nix/pull/6086 search speed: $ time nix search nixpkgs ripgrep * legacyPackages.x86_64-linux.ripgrep (13.0.0) A utility that combines the usability of The Silver Searcher with the raw speed of grep * legacyPackages.x86_64-linux.ripgrep-all (0.9.6) Ripgrep, but also search in PDFs, E-Books, Office documents, zip, tar.gz, and more * legacyPackages.x86_64-linux.vgrep (2.6.0) User-friendly pager for grep/git-grep/ripgrep real 0m0.514s user 0m0.494s sys 0m0.019s We're trying to improve the UX with the new CLI. Precisely to improve the developer experience and quality. Any other major gripes?
- sontek 5y ago
  Yeah, the UX for the new search although faster is more of a problem for me. When it returns `legacyPackages.x86_64-linux.ripgrep` that makes me think "oh no, I don't want the legacy package. I want the good one", but no non-legacy package is returned. Also the name is confusing, it return `x86_64-linux` on linux and `x86_64-darwin` but why does that information need to be included? Then it brings up the problem if I need to install with the whole long string or if I can just install with `ripgrep`. The other big grip I have with the new CLI is the installed packages. If you run: > nix profile list You get a gob of mostly unreadable text scrolling through your screen: 72 flake:nixpkgs#legacyPackages.x86_64-darwin.toilet github:NixOS/nixpkgs/19574af0af3ffaf7c9e359744ed32556f34536bd#legacyPackages.x86_64-darwin.toilet /nix/store/hnvdydra5syylxnxwj2fmn91aqwz26p6-toilet-0.3 73 flake:nixpkgs#legacyPackages.x86_64-darwin.asdf-vm github:NixOS/nixpkgs/b66b39216b1fef2d8c33cc7a5c72d8da80b79970#legacyPackages.x86_ 64-darwin.asdf-vm /nix/store/skk5pfhjnj49gw184jwivd5wakxx5g23-asdf-vm-0.8.1 and for some reason includes a bunch of duplicate packages, so its very confusing: > nix profile list|grep lolcat 22 flake:nixpkgs#legacyPackages.x86_64-darwin.lolcat github:NixOS/nixpkgs/19574af0af3ffaf7c9e359744ed32556f34536bd#legacyPackages.x86_64-darwin.lolcat /nix/store/zxnkjsimmcvv0jnwsy5jxxmjak01k52f-lolcat-100.0.1 46 flake:nixpkgs#legacyPackages.x86_64-darwin.lolcat github:NixOS/nixpkgs/19574af0af3ffaf7c9e359744ed32556f34536bd#legacyPackages.x86_64-darwin.lolcat /nix/store/zxnkjsimmcvv0jnwsy5jxxmjak01k52f-lolcat-100.0.1 71 flake:nixpkgs#legacyPackages.x86_64-darwin.lolcat github:NixOS/nixpkgs/19574af0af3ffaf7c9e359744ed32556f34536bd#legacyPackages.x86_64-darwin.lolcat /nix/store/zxnkjsimmcvv0jnwsy5jxxmjak01k52f-lolcat-100.0.1 Same package name, hash, and version listed 3 times for some reason. I ended up writing an alias that would give me a readable list: > which npl npl: aliased to nix profile list|awk '{print $2}'|sort|uniq|sed s/flake:nixpkgs#legacyPackages.x86_64-//g|sed s/darwin\.//g > npl argocd asdf-vm aws-vault awscli2
aidenn0 5y ago
FWIW I found Nix to be much better when I stopped using nix-env

by sontek 5y ago

Izkata 5y ago

It's the "-A" that requires "nixpkgs." for installing. It's slower and probably there's other details I'm missing (the complexity rarely makes me want to dig deeper than these bare-basic nix-env commands since I only use it for a couple of things), but you can do "nix-env -i ripgrep".

soraminazuki 5y ago
Actually, -A makes it faster and more precise about what you want to install. The Nixpkgs repository is defined as large associative array containing packages. When "-A nixpkgs.ripgrep" is specified, nix-env looks up the associative array using the key "ripgrep". That in theory should take constant time regardless of the size of Nixpkgs. When -A isn't specified, nix-env searches the entire associative array for a package whose "name" attribute looks similar to "ripgrep." That takes more time as the size of Nixpkgs grows. It's also less precise because the "name" attribute for packages aren't guaranteed to be unique, unlike a key for an associative array. It doesn't do an exact match either, because the "name" attribute also includes version numbers by convention. For uninstalling, nix-env doesn't have the -A flag, because it has to operate on the set of installed packages, not Nixpkgs.
- jeddy3 5y ago
  Yeah, thats what he is saying as well, the long parenthesis makes it kinda hard to parse, but you are saying the same thing.

bogota 5y ago

This has been my experience as well. I have wanted so badly to love it and try and introduce it into many different systems to provide consistent tooling but its just too slow. I also found that many people had a hard time picking it up myself included.

chrisweekly 5y ago

Thank you sincerely for this public service announcement. We might joke about getting "nerd-sniped", but it really can be difficult to predict ROI when choosing which new things merit attention. This glimpse into real DX issues probably saved me (and many others) some real time and frustration. OTOH I want to encourage those who do have the time and inclination to get involved and improve those things and help reify the good ideas / fulfill their potential.

_huayra_ 5y ago
I really wanted to love Nix and tried my best to ease into it, e.g. using it as a "pip" replacement for Python, then managing dotfiles, etc. Maybe I chose the wrong side of the "flakes schism", but it was so foggy and unclear how one went from "lazily evaluated attribute set" to "an actual system". I really wish this was written in something even like Haskell or Ocaml, that has actual real language support and tooling. Troubleshooting attribute errors was just not possible and I gave up (GUIX looks awesome, but I can't really use shepherd unfortunately). It really says something when I found myself looking to Gentoo as an "easier, well-thought-out alternative"...
- carlmr 5y ago
  >I really wish this was written in something even like Haskell or Ocaml, that has actual real language support and tooling. Troubleshooting attribute errors was just not possible and I gave up (GUIX looks awesome, but I can't really use shepherd unfortunately). The 3 times I've tried to use Nix (and invariably gave up), I always came to this conclusion. A language like F#/OCaml with great typing and type inference and good auto completion could get us half the way to usability.
  - Smaug123 5y ago
    Nickel Is Coming! https://github.com/tweag/nickel https://github.com/tweag/nickel, e.g. https://github.com/tweag/nickel/blob/master/examples/polymorphism/polymorphism.ncl https://github.com/tweag/nickel/blob/master/examples/polymor... . Looks really exciting to me!

soraminazuki 5y ago

For installing a package, you have to specify the package repository. For uninstalling, you don't because you're operating against a separate repository containing locally installed packages. This should be the same for the new CLI too. Looking at the manual[1], instead of: nix profile remove nixpkgs#ripgrep You'd probably need to run: nix profile remove packages.x86_64-linux.ripgrep For searching packages, nix search nixpkgs ripgrep is faster than nix-env -qaP ripgrep But I find the online search UI[2] to be far more superior. [1]: https://nixos.org/manual/nix/unstable/command-ref/new-cli/nix3-profile-remove.html https://nixos.org/manual/nix/unstable/command-ref/new-cli/ni... [2]: https://search.nixos.org/packages https://search.nixos.org/packages

brongondwana 5y ago
This sounds like an unpleasant UX. Am not compelled to try.
- soraminazuki 5y ago
  If Nix was about replacing apt's CLI syntax, then sure. But its promises are more than that.
  - brongondwana 5y ago
    Is there any data on how many people care about said promises as opposed to care about not having an actively hostile and prickly interface? Because I enjoyed tinkering with this kind of thing in my 20s, but in my 40s I just want something that I can use without having to memorize a ton of arcania, and that lets me solve my problem and get back to my actual goals. I never wake up saying "today I want to install a package on my computer and revel in my extreme knowledge of how my package manager works". I wake up with plans, and installing a package might be necessary to achieve them.
    - soraminazuki 5y ago
      To be clear, Nix's CLI syntax is what it is because of the following requirements: * Provide the ability to create a new package by extending an existing package definition programatically * Provide the ability to have multiple variations of similar packages To satisfy those requirements, you need a way to uniquely specify packages by its precise location of its definition. It does not interact well with apt's model of having a central package repository assign names for every known package. > "today I want to install a package on my computer and revel in my extreme knowledge of how my package manager works" Was this straw man mockery really necessary?`

Jaepa 5y ago

I'm going to preempt this with anything not explicitly forbidden is allowed, lest this come off as "you holding it wrong". Using the CLI to add/remove package is considered kind of an antipattern in nix. The correct way to write a fair bit of Nix (the language) to install and configure things. That then can be versioned, forked, etc. There are a lot of really cool parts of Nix, but they're under a ball of rough edges.

sontek 5y ago
Yeah, the hard part is maintaining a file just to have the tools you want is a major hurdle that is not reasonable for most people to jump over. If I'm working I might do something like this: curl example.com/data.json | jq ... and I'll realize I don't have `jq` installed. I do not want to open vim, edit a configuration file, and then re-run a command to rebuild my system. I just want jq. I can't change context like that just to get a package. I understand this isn't aligned with the purity stance that nix has but if they were able to allow this use case, it would most likely get more people doing it the right way eventually. I can't drink all the kool-aid at once, I really need to replace bits of my workflow at a time and I can't do that with nix currently. The approach I've laid out in my original comment (using `nix-env`) provides a bad developer experience and makes me not able(willing?) to move forward with the adopting more of the practices. If the initial experience was better, I'd invest more time learning more.
- Jaepa 5y ago
  Oh I don't disagree. The onboarding experience is terrible. * You have to learn a new and kind of knobbly single use language. * If you are going the NixOS route there's the non-trival learning curve for that as well. * And the package manager itself is more than a little confusing. As for the workflow. I use NixOS on my personal machine. I'm fine with it because its typically pretty quick and happens infrequently. Buuuuuuut I wouldn't really advocate for NixOS. Its cool. I like it. I'm never going to recoop the time and effort I spent learning how to use it.
- ayushnix 5y ago
  > Yeah, the hard part is maintaining a file just to have the tools you want I'd be okay doing that to install packages but what I don't like is the N number of ways to install packages. Do I use nix-env? Do I use the new nix CLI? Do I make an entry in configuration.nix? Do I use this thing called flakes which is marked as experimental but almost everyone seems to be onboard with it? There's no central and definitive source of documentation either. There's the official NixOS website, nix pills, nixos.wiki, blog posts from prominent developers, and other sources I don't remember. Seems like a fragmented mess to me.

MarcScott 5y ago

This is probably because I'm on NixOS but I have never used nix-env to install anything. I use nix-shell to test out a package, or use one that I only need temporarily. If I need a package for a particular build then it gets added to my config files, and I rebuild switch. If I don't want that package anymore, then I remove it from my config and do another rebuild. I've never really understood the use case for nix-env.

huijzer 5y ago
I once spend 2 hours on trying to get a newer version of nodejs on my system. Turned out that I had used nix-env a while back to install it and that had priority over the rebuild-switch :| So, I agree. Very risky way of managing nix
- kreetx 5y ago
  nix-env has been easier to use for a new use compared to having a configuration.nix, using home-manager etc, but once you start using any of the latter then just remove everything installed with nix-env (and use nix-shell for one-offs).
  - _andrei_ 5y ago
    nix-env -e "*" # remove all packages
iamevn 5y ago
for those one-off times I want to just jump into a shell with, say, ranger available, it's as simple as $ nix shell nixpkgs#ranger if I am starting up a project that needs a tool, I just throw together a simple shell.nix in a folder for the project and run $ nix shell from that folder. there's ways to set it up so you automatically switch to a shell with the specified packages (iirc with direnv just like you'd do it for python venvs) but I haven't felt the need yet. https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3-shell.html https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3... https://nixos.wiki/wiki/Development_environment_with_nix-shell https://nixos.wiki/wiki/Development_environment_with_nix-she...

colordrops 5y ago

It's unfortunate that this is the top comment, as it might unfairly turn potential users off to Nix. Imperative command line installation of packages with nix is contrary the model of how it is supposed to work, and is deprecated. I've never used it once.

GlennS 5y ago
Is that documented anywhere? I've been using Nix for about 6 years now, and have mostly been using `nix-env -iA`, `nix-env -qaP --description` and `nix-env -e` the whole time.
- colordrops 5y ago
  I'm much newer user and admittedly the documentation is not great, so I've used forums and IRC a lot and from what I've gathered, the movement is towards declarative reproduceability. This is the reason for the development of flakes. I saw installation of packages using nix-env in many search results and tutorial pages but newer comments seem to indicate that this is no longer recommended, and it fully makes sense to me. I want to get my machine back to the same state using my config checked into git, and installing imperatively using nix-env clearly goes against this.
- rgoulter 5y ago
  > I've been using Nix for about 6 years now, and have mostly been using `nix-env -iA`, `nix-env -qaP --description` and `nix-env -e` the whole time. I'd suggest "declarative package management" as a level-up above this. https://nixos.org/manual/nixpkgs/stable/#sec-declarative-package-management https://nixos.org/manual/nixpkgs/stable/#sec-declarative-pac...
  - GlennS 5y ago
    Thanks very much!
PoignardAzur 5y ago
The thing is, it might be contrary to the underlying model of the OS, but it's how a lot of people want to do it. To give a similar example: in the Rust programming language, dependencies are declared in a TOML file. While the dependencies are declarative, there's also a popular tool (that's being added to the main project) that lets you do cargo add awesome-thing-rs and add the dependency to your project, and edits the config file for you. That's it: no combinations to remember, no weird use cases, no unintuitive error messages, you just say "I want to add X" and then X is added. I don't see why Nix couldn't do the same.

mongol 5y ago

I just started to install nix and my first impression is the opposite of terrible. The way it describes what it will do in detail, before doing it, I think is _excellent_. Of course, I have not started using nix yet but to me this shows some attention to detail that developers appreciate and that most other tools don't bother with. I am hopeful I will like it.

Smaug123 5y ago
The installer is absolutely first rate, but I would strongly recommend asking for help at discourse.nixos.org as soon as you start getting stuck (which will definitely happen, probably rather early).
throwamon 5y ago
Funny you say that, because the installer is about the only thing that is helpful like that. Everything else from there is basically "what do you mean you didn't read the entirety of the official manual, and the deprecated wiki, and the unofficial wiki, and the other wiki, and Discourse, and IRC, and random blog posts, and just learn to read undocumented inconsistent idiosyncratic source code already!?" They do help you really quick on Matrix though.

otabdeveloper4 5y ago

Nix doesn't install packages. Nix is just an isolation and sandboxing system for build artefacts. NixOs can install packages, but it doesn't use nix-env.

tomberek 5y ago

profile removal: Fixed in https://github.com/NixOS/nix/pull/6086 https://github.com/NixOS/nix/pull/6086 search speed: $ time nix search nixpkgs ripgrep * legacyPackages.x86_64-linux.ripgrep (13.0.0) A utility that combines the usability of The Silver Searcher with the raw speed of grep * legacyPackages.x86_64-linux.ripgrep-all (0.9.6) Ripgrep, but also search in PDFs, E-Books, Office documents, zip, tar.gz, and more * legacyPackages.x86_64-linux.vgrep (2.6.0) User-friendly pager for grep/git-grep/ripgrep real 0m0.514s user 0m0.494s sys 0m0.019s We're trying to improve the UX with the new CLI. Precisely to improve the developer experience and quality. Any other major gripes?

sontek 5y ago
Yeah, the UX for the new search although faster is more of a problem for me. When it returns `legacyPackages.x86_64-linux.ripgrep` that makes me think "oh no, I don't want the legacy package. I want the good one", but no non-legacy package is returned. Also the name is confusing, it return `x86_64-linux` on linux and `x86_64-darwin` but why does that information need to be included? Then it brings up the problem if I need to install with the whole long string or if I can just install with `ripgrep`. The other big grip I have with the new CLI is the installed packages. If you run: > nix profile list You get a gob of mostly unreadable text scrolling through your screen: 72 flake:nixpkgs#legacyPackages.x86_64-darwin.toilet github:NixOS/nixpkgs/19574af0af3ffaf7c9e359744ed32556f34536bd#legacyPackages.x86_64-darwin.toilet /nix/store/hnvdydra5syylxnxwj2fmn91aqwz26p6-toilet-0.3 73 flake:nixpkgs#legacyPackages.x86_64-darwin.asdf-vm github:NixOS/nixpkgs/b66b39216b1fef2d8c33cc7a5c72d8da80b79970#legacyPackages.x86_ 64-darwin.asdf-vm /nix/store/skk5pfhjnj49gw184jwivd5wakxx5g23-asdf-vm-0.8.1 and for some reason includes a bunch of duplicate packages, so its very confusing: > nix profile list|grep lolcat 22 flake:nixpkgs#legacyPackages.x86_64-darwin.lolcat github:NixOS/nixpkgs/19574af0af3ffaf7c9e359744ed32556f34536bd#legacyPackages.x86_64-darwin.lolcat /nix/store/zxnkjsimmcvv0jnwsy5jxxmjak01k52f-lolcat-100.0.1 46 flake:nixpkgs#legacyPackages.x86_64-darwin.lolcat github:NixOS/nixpkgs/19574af0af3ffaf7c9e359744ed32556f34536bd#legacyPackages.x86_64-darwin.lolcat /nix/store/zxnkjsimmcvv0jnwsy5jxxmjak01k52f-lolcat-100.0.1 71 flake:nixpkgs#legacyPackages.x86_64-darwin.lolcat github:NixOS/nixpkgs/19574af0af3ffaf7c9e359744ed32556f34536bd#legacyPackages.x86_64-darwin.lolcat /nix/store/zxnkjsimmcvv0jnwsy5jxxmjak01k52f-lolcat-100.0.1 Same package name, hash, and version listed 3 times for some reason. I ended up writing an alias that would give me a readable list: > which npl npl: aliased to nix profile list|awk '{print $2}'|sort|uniq|sed s/flake:nixpkgs#legacyPackages.x86_64-//g|sed s/darwin\.//g > npl argocd asdf-vm aws-vault awscli2

aidenn0 5y ago

FWIW I found Nix to be much better when I stopped using nix-env