7 ms·

I wish Nix would just get rid of nix-env. It's not the way it's meant to be used, you should be using "nix run" or nix-shell for temporary usage, and home-manag

by Shoue 5y ago

I wish Nix would just get rid of nix-env. It's not the way it's meant to be used, you should be using "nix run" or nix-shell for temporary usage, and home-manager for dotfiles and user dependencies. Using Nix like an imperative package manager is not really an improvement over existing ones, the declarative bit is where it truly shines.

chaorace 5y ago
Agreed, but perhaps they should officially adopt home-manager then? It felt strange to me that the best way to be using nix was a separate community project.
- tnzm 5y ago
  I don't use nix-env or home-manager. On my NixOS workstation everything (outside of nix-shells) is installed via environment.systemPackages. And I do wish there was an easy way to add stuff to install packages without rebuilding the whole system - I guess that's what nix-env is for but if I went with that I would the "single editable config file that you can put in VCS" aspect. I think nix-env uses profiles, which are implemented collection of symlinks to the Nix store - guess I could still version those...?
  - danieldk 5y ago
    https://nixos.org/manual/nixpkgs/stable/#sec-declarative-package-management https://nixos.org/manual/nixpkgs/stable/#sec-declarative-pac...
  - chriswarbo 5y ago
    You can define a package that contains a bunch of other things, e.g. I use packages like 'devCli', 'netGui', etc. (I actually put these in my systemPackages on NixOS and nix-darwin, but they would also work with nix-env) http://chriswarbo.net/git/nix-config/git/branches/master/overrides/metaPackages.nix.raw.html http://chriswarbo.net/git/nix-config/git/branches/master/ove...
- otabdeveloper4 5y ago
  At the moment the happy path for Nix is using it in the same space that Docker is used now - for providing reproducible dev/prod environments for server backends. (And in fact Docker and Nix complement and play nice with each other.) You could theoretically use Nix for managing user apps too, but that's a niche use case and (as you found out) not in a working state.
  - jpe90 5y ago
    So for the happy path, are you declaring the entire development toolchain on a project by project basis? Any chance you have some recommended resources that show the way you're using it? I was hoping to use it for Haskell but I'd love to see a guide targeted to new users that shows what you're describing.
    - otabdeveloper4 5y ago
      Yeah, each project has its own default.nix that might look something like this: { pkgs ? import (fetchTarball "https://github.com/NixOS/nixpkgs/archive/cd63096.tar.gz") { } } : with pkgs; let mypackage = callPackage ./mypackage.nix { stdenv = stdenv; python = python3; }; in dockerTools.buildImage { contents = [ mypackage ]; } You then write a package definition in mypackage.nix, following the template of packaging things in nixpkgs. (Dev environments work in a similar fashion except with mkShell instead of dockerTools.buildImage.) I haven't used Nix flakes but I think it develops this simple idea further.
andrewla 5y ago
Hear hear! The desire to make the experience "familiar" for users of apt causes way more confusion once you start actively using it.
domenkozar 5y ago
That's the long term plan, once the new command line stabilizes.
throwaway894345 5y ago
I agree, but I think nix-env is only the tip of the iceberg with respect to bad upfront experiences. If you try to make a Go package, for example, you end up having to provide a hash. To generate the hash `vendorSha256`, you have to run `nix-prefetch`, but that program is broken on MacOS. I mentioned elsewhere that I spent a weekend working with the Nix discord to try to install VS Code with some extensions for Rust development, and we collectively couldn't figure it out (I'm not using NixOS, but just Nix the package manager). In the past I've tried to package a simple Python app thinking it would be a simple reference to a pypi package, and I ended up having to package a never-ending matrix of the most obscure C dependencies and ultimately gave up. Maybe if I were doing Haskell development I might find the Nix happy path, but for now I just have a nix shell that installs a few basic CLI utilities and that's the only way I've managed to use Nix successfully. Further, any time I have to do anything in nixpkgs, I find that everything is a slog--since there are so few imports (and because the Nix people don't believe in documentation or types or even sane file/directory organization), in order to find the "shape" of argument `foo` to the Nix package function `Bar`, I need to grep the whole nixpkgs repo for something that uses `Bar` and then figure out what it's passing in for the `foo` parameter. Often `Bar` is passed to several other functions (defined in several other files) before it's called and the thing that gets passed in for the `foo` parameter might be the return value of a function which itself is returning the result of some other function (each of which is defined in other files), etc. This results in a combinatorial explosion of inefficiently grepping around the codebase just to get the type of a symbol (something that would come for free in a statically typed language). I'm a big believer in the Nix approach to builds, and that this approach holds a lot of potential for DevOps (especially CI/CD); however, there are so many practical problems with Nix and the community doesn't seem especially interested in fixing them. Of course, what volunteers spend their time on is there prerogative, I could volunteer my time rather than criticize, shame on me, etc but it's a loss for the broader world. Personally I would really like to see a community with the ethos of the Rust community pick up the torch and try to build something inspired by Nix, but perhaps with more pragmatic choices (e.g., instead of inventing an obscure scripting language, they might use something more familiar and thus easier on new users; rather than the chaos of nixpkgs, they might give users a type system and/or good editor tooling; rather than the difficult-to-Google "Nix" label, they might pick something a bit less overloaded; etc).
epistasis 5y ago
As somebody who wants to try out nix, but has almost no knowledge of it, I would like to find resources that show the "right" way, or perhaps the "best" way to use nix. Do you know of existing documentation that explains that, according to your opinion?
- 2mol 5y ago
  I think https://nix.dev https://nix.dev is what you are looking for. It's a really great resource (and no need to go all in and do _everything_ in nix)
  - jpe90 5y ago
    This is orders of magnitude more useful than the official docs.
    - nextos 5y ago
      The unofficial wiki is also very helpful: https://nixos.wiki/ https://nixos.wiki/
  - danmur 5y ago
    Ahh that's great, thank you. I've been running nixos on my laptop for a year but have never come across that somehow.
- jonringer117 5y ago
  I made a few videos, https://www.youtube.com/channel/UC-cY3DcYladGdFQWIKL90SQ https://www.youtube.com/channel/UC-cY3DcYladGdFQWIKL90SQ . However, I need to produce more and of higher quality.
Ericson2314 5y ago
At the very least, get rid of `-u`. Some parts of nix-env are used underneath the hood for NixOS and home-manager I beleive, but not that.
gmfawcett 5y ago
Eh, I don't think nix-env is all that bad. Put it this way: nix-shell lets you dip your toes in the water, without learning the Nix language. Amazing value added... but sometimes it's annoying that it forgets that package you used yesterday. nix-env lets you "install" software, without learning the Nix language. Great, now I can use that Nix package repeatedly without having to nix-shell it. We're still better off than "apt install" at this point, and it's no harder than that. Everything else -- nixos config, home-manager, flakes, overlays, etc. -- requires Nix language knowledge, and non-superficial comfort level with the Nix data model (nixpkgs, attribute sets, and a very long tail of other things). Nix-env is a beneficial stepping stone for converting dabblers into diehards, and is one of the Nash equilibria for some Nix users. (i.e., not everyone wants to learn the language and drink the koolaid, they just want to enjoy some additional benefits beyond nix-shell.)
- jonringer117 5y ago
  The issue with `nix-env` is how it tries to decide a later version. Python also has this issue, because it will see that python3.7 has a newer version called `python3.10a3`, and installs the alpha/dev version, instead of the expected python3.7.x Honestly, if people just used nix for `shell.nix` in projects, it's still major value added
  - gmfawcett 5y ago
    Is there a tool that works something like this: - mkdir myproject ; cd myproject - nix-shell-env init # creates an "empty-ish" shell.nix - nix-shell-env install nixpkgs.whatever # adds dep. to shell.nix - nix-shell # activate it So you don't have to learn any Nix-language / nixpkgs ropes, but can still have a viable shell.nix built for your project. I could see that being a nice stepping stone between "nix-shell -p" and "learning the language."
jonringer117 5y ago
at least now, people get recommend to use `nix-shell -p <pkg>` when something is missing in NixOS

by Shoue 5y ago

chaorace 5y ago

Agreed, but perhaps they should officially adopt home-manager then? It felt strange to me that the best way to be using nix was a separate community project.

tnzm 5y ago
I don't use nix-env or home-manager. On my NixOS workstation everything (outside of nix-shells) is installed via environment.systemPackages. And I do wish there was an easy way to add stuff to install packages without rebuilding the whole system - I guess that's what nix-env is for but if I went with that I would the "single editable config file that you can put in VCS" aspect. I think nix-env uses profiles, which are implemented collection of symlinks to the Nix store - guess I could still version those...?
- danieldk 5y ago
  https://nixos.org/manual/nixpkgs/stable/#sec-declarative-package-management https://nixos.org/manual/nixpkgs/stable/#sec-declarative-pac...
- chriswarbo 5y ago
  You can define a package that contains a bunch of other things, e.g. I use packages like 'devCli', 'netGui', etc. (I actually put these in my systemPackages on NixOS and nix-darwin, but they would also work with nix-env) http://chriswarbo.net/git/nix-config/git/branches/master/overrides/metaPackages.nix.raw.html http://chriswarbo.net/git/nix-config/git/branches/master/ove...
otabdeveloper4 5y ago
At the moment the happy path for Nix is using it in the same space that Docker is used now - for providing reproducible dev/prod environments for server backends. (And in fact Docker and Nix complement and play nice with each other.) You could theoretically use Nix for managing user apps too, but that's a niche use case and (as you found out) not in a working state.
- jpe90 5y ago
  So for the happy path, are you declaring the entire development toolchain on a project by project basis? Any chance you have some recommended resources that show the way you're using it? I was hoping to use it for Haskell but I'd love to see a guide targeted to new users that shows what you're describing.
  - otabdeveloper4 5y ago
    Yeah, each project has its own default.nix that might look something like this: { pkgs ? import (fetchTarball "https://github.com/NixOS/nixpkgs/archive/cd63096.tar.gz") { } } : with pkgs; let mypackage = callPackage ./mypackage.nix { stdenv = stdenv; python = python3; }; in dockerTools.buildImage { contents = [ mypackage ]; } You then write a package definition in mypackage.nix, following the template of packaging things in nixpkgs. (Dev environments work in a similar fashion except with mkShell instead of dockerTools.buildImage.) I haven't used Nix flakes but I think it develops this simple idea further.

andrewla 5y ago

Hear hear! The desire to make the experience "familiar" for users of apt causes way more confusion once you start actively using it.

domenkozar 5y ago

That's the long term plan, once the new command line stabilizes.

throwaway894345 5y ago

I agree, but I think nix-env is only the tip of the iceberg with respect to bad upfront experiences. If you try to make a Go package, for example, you end up having to provide a hash. To generate the hash `vendorSha256`, you have to run `nix-prefetch`, but that program is broken on MacOS. I mentioned elsewhere that I spent a weekend working with the Nix discord to try to install VS Code with some extensions for Rust development, and we collectively couldn't figure it out (I'm not using NixOS, but just Nix the package manager). In the past I've tried to package a simple Python app thinking it would be a simple reference to a pypi package, and I ended up having to package a never-ending matrix of the most obscure C dependencies and ultimately gave up. Maybe if I were doing Haskell development I might find the Nix happy path, but for now I just have a nix shell that installs a few basic CLI utilities and that's the only way I've managed to use Nix successfully. Further, any time I have to do anything in nixpkgs, I find that everything is a slog--since there are so few imports (and because the Nix people don't believe in documentation or types or even sane file/directory organization), in order to find the "shape" of argument `foo` to the Nix package function `Bar`, I need to grep the whole nixpkgs repo for something that uses `Bar` and then figure out what it's passing in for the `foo` parameter. Often `Bar` is passed to several other functions (defined in several other files) before it's called and the thing that gets passed in for the `foo` parameter might be the return value of a function which itself is returning the result of some other function (each of which is defined in other files), etc. This results in a combinatorial explosion of inefficiently grepping around the codebase just to get the type of a symbol (something that would come for free in a statically typed language). I'm a big believer in the Nix approach to builds, and that this approach holds a lot of potential for DevOps (especially CI/CD); however, there are so many practical problems with Nix and the community doesn't seem especially interested in fixing them. Of course, what volunteers spend their time on is there prerogative, I could volunteer my time rather than criticize, shame on me, etc but it's a loss for the broader world. Personally I would really like to see a community with the ethos of the Rust community pick up the torch and try to build something inspired by Nix, but perhaps with more pragmatic choices (e.g., instead of inventing an obscure scripting language, they might use something more familiar and thus easier on new users; rather than the chaos of nixpkgs, they might give users a type system and/or good editor tooling; rather than the difficult-to-Google "Nix" label, they might pick something a bit less overloaded; etc).

epistasis 5y ago

As somebody who wants to try out nix, but has almost no knowledge of it, I would like to find resources that show the "right" way, or perhaps the "best" way to use nix. Do you know of existing documentation that explains that, according to your opinion?

2mol 5y ago
I think https://nix.dev https://nix.dev is what you are looking for. It's a really great resource (and no need to go all in and do _everything_ in nix)
- jpe90 5y ago
  This is orders of magnitude more useful than the official docs.
  - nextos 5y ago
    The unofficial wiki is also very helpful: https://nixos.wiki/ https://nixos.wiki/
- danmur 5y ago
  Ahh that's great, thank you. I've been running nixos on my laptop for a year but have never come across that somehow.
jonringer117 5y ago
I made a few videos, https://www.youtube.com/channel/UC-cY3DcYladGdFQWIKL90SQ https://www.youtube.com/channel/UC-cY3DcYladGdFQWIKL90SQ . However, I need to produce more and of higher quality.

Ericson2314 5y ago

At the very least, get rid of `-u`. Some parts of nix-env are used underneath the hood for NixOS and home-manager I beleive, but not that.

gmfawcett 5y ago

Eh, I don't think nix-env is all that bad. Put it this way: nix-shell lets you dip your toes in the water, without learning the Nix language. Amazing value added... but sometimes it's annoying that it forgets that package you used yesterday. nix-env lets you "install" software, without learning the Nix language. Great, now I can use that Nix package repeatedly without having to nix-shell it. We're still better off than "apt install" at this point, and it's no harder than that. Everything else -- nixos config, home-manager, flakes, overlays, etc. -- requires Nix language knowledge, and non-superficial comfort level with the Nix data model (nixpkgs, attribute sets, and a very long tail of other things). Nix-env is a beneficial stepping stone for converting dabblers into diehards, and is one of the Nash equilibria for some Nix users. (i.e., not everyone wants to learn the language and drink the koolaid, they just want to enjoy some additional benefits beyond nix-shell.)

jonringer117 5y ago
The issue with `nix-env` is how it tries to decide a later version. Python also has this issue, because it will see that python3.7 has a newer version called `python3.10a3`, and installs the alpha/dev version, instead of the expected python3.7.x Honestly, if people just used nix for `shell.nix` in projects, it's still major value added
- gmfawcett 5y ago
  Is there a tool that works something like this: - mkdir myproject ; cd myproject - nix-shell-env init # creates an "empty-ish" shell.nix - nix-shell-env install nixpkgs.whatever # adds dep. to shell.nix - nix-shell # activate it So you don't have to learn any Nix-language / nixpkgs ropes, but can still have a viable shell.nix built for your project. I could see that being a nice stepping stone between "nix-shell -p" and "learning the language."

jonringer117 5y ago

at least now, people get recommend to use `nix-shell -p <pkg>` when something is missing in NixOS