4 ms·

This, 100%. Pain points I've run into: 1. Lack of clarity as to how language/application package managers interact with Nix (pip, stack, Vundle). Pretty much

This, 100%. Pain points I've run into: 1. Lack of clarity as to how language/application package managers interact with Nix (pip, stack, Vundle). Pretty much every time I've asked about this, I've been told to go use `nix-shell` or to install things through Nix. Increasingly, when I get odd behavior with applications I install through Nix, my first resort is to uninstall the Nix version and install it from apt; it might be a bit older, but I'm sure it'll work as expected. I've went through the apt package -> Nix package -> apt package cycle three times from what I remember off the top of my head, with python/ipython, Haskell tooling, and Vim. 2. Nix on Ubuntu feels like a second class citizen. Things that interact with graphics drivers often don't work properly, e.g. video players. (I understand that there are technical reasons why this is the case, but there's no warning that this is the case.) There only appears to be online package search for NixOS (https://nixos.org/nixos/packages.html# https://nixos.org/nixos/packages.html#) and not for Nix on other platforms. Nox helps, but it doesn't seem to be the same feature wise (no ability to see the info you get by clicking the package name) and is also slow. 3. In general package quality is not great for less frequently used packages. Inkscape was missing potrace for a while. Rarely used packages go unmaintained. 4. Poor CLI. Needing to pass `-A` to a lot of commands to use them the "right way" smells of a poorly thought out design. No feedback or suggestions if you type the wrong thing to `nix-env -e`. It looks like there are major changes to this in 2.0, so this might have been improved. Despite being someone who's gotten their toes wet contributing to nixpkgs, I'm likely not going to be installing Nix when I upgrade from Ubuntu 16.04 to 18.04.

thomastjeffery 9y ago
> Needing to pass `-A` to a lot of commands to use them the "right way" smells of a poorly thought out design. That stems from the namespace problem that Nix devs seem to think doesn't exist. Packages that have the same name, or belong in a different namespace (hackage, pip, etc.) are confusing to find from a user's perspective. The real problem is that every package in a channel has to go into the same global namespace. Practically every package manager has this problem, but, in my opinion, Nix deals with it the most poorly. To make matters worse, it isn't obvious which namespace .nix files are supposed to reference, or what functions exist globally. Nix really does need a lot of UX work, and I'm glad to hear it is getting some.
pknopf 9y ago
I built Darch to give me what I crave from NixOS. Immutability. https://godarch.com/ https://godarch.com/
- grantwu 9y ago
  What does... how is this relevant to anything I said?
  - taohansen 9y ago
    If I may rush to the commenter's rescue: Darch addresses your issues with NixOS by combining a familiar set of tools (Arch Linux) with stateless architecture. Its a fantastic welding of extreme package availability and best-in-class documentation with declarative dependability.
    - grantwu 9y ago
      It's not clear to me that this really solves the same problems that Nix does. I'd imagine this solution inherits any problems that pacman has. The Arch wiki states that "if two packages depend on the same library, upgrading only one package might also upgrade the library (as a dependency), which might then break the other package which depends on an older version of the library." (https://wiki.archlinux.org/index.php/System_maintenance https://wiki.archlinux.org/index.php/System_maintenance) This is one of the problems Nix does not have by design; in fact Nix lets you mix and match packages painlessly. This also doesn't seem to allow unprivileged users to install packages, which is kind of a side benefit of using Nix. Docker-esque solutions' issues with reproducibility are well known; I look at https://godarch.com/concepts/images/ https://godarch.com/concepts/images/, particularly how packages are installed: #!/usr/bin/env bash pacman -S steam --noconfirm and I see the same issues that https://blog.wearewizards.io/why-docker-is-not-the-answer-to-reproducible-research-and-why-nix-may-be https://blog.wearewizards.io/why-docker-is-not-the-answer-to... warns of. Heck the author even admits this is the case in an adjacent comment: "I want a machine that can be declared and rebuilt deterministically (at least semi-deterministically, rolling distro and all)" (emphasis mine). Also, frankly, I don't want to run my personal computer like a server, with complete immutability and the need to build fat image files every time I want to try out an additional program. That seems to me like a workflow that's better suited for servers where spending a few minutes for a deploy isn't a blocking operation, and where stateless service design is considered best practice.
lukego 9y ago
> Rarely used packages go unmaintained. I have a related pain-point. I want to maintain nix packages on their own long-lived branches. I also want to base these branches on the latest stable release rather than unstable. This would require upstream nixpkgs to treat my package branches as equal peers and to pull their changes with 'git merge' like in the Linux kernel workflow. Status quo seems to be that upstream expects people to work directly on the unstable branch and to make contributions using short-lived topic branches that can be rebased at any time. I spent a lot of time packaging Pharo Smalltalk for nixpkgs but I found it too complicated to stay in sync with upstream and so I ended up orphaning that package and redoing it on a downstream overlay repo that insulates me from the upstream nixpkgs workflow. This was discussed a bit over at https://github.com/NixOS/nixpkgs/issues/27312 https://github.com/NixOS/nixpkgs/issues/27312 but perhaps didn't get enough visibility because I also stubbornly prefer to work on Github and don't follow the mailing list.
Ericson2314 9y ago
> Poor CLI. Did you even read the OP? Nix 2.0 has begun to fix this as one of its highest priorities.
- grantwu 9y ago
  Did you even read my comment? I acknowledged that.
  - Ericson2314 9y ago
    My bad. It is at the end of that.

thomastjeffery 9y ago

> Needing to pass `-A` to a lot of commands to use them the "right way" smells of a poorly thought out design. That stems from the namespace problem that Nix devs seem to think doesn't exist. Packages that have the same name, or belong in a different namespace (hackage, pip, etc.) are confusing to find from a user's perspective. The real problem is that every package in a channel has to go into the same global namespace. Practically every package manager has this problem, but, in my opinion, Nix deals with it the most poorly. To make matters worse, it isn't obvious which namespace .nix files are supposed to reference, or what functions exist globally. Nix really does need a lot of UX work, and I'm glad to hear it is getting some.

pknopf 9y ago

I built Darch to give me what I crave from NixOS. Immutability. https://godarch.com/ https://godarch.com/

grantwu 9y ago
What does... how is this relevant to anything I said?
- taohansen 9y ago
  If I may rush to the commenter's rescue: Darch addresses your issues with NixOS by combining a familiar set of tools (Arch Linux) with stateless architecture. Its a fantastic welding of extreme package availability and best-in-class documentation with declarative dependability.
  - grantwu 9y ago
    It's not clear to me that this really solves the same problems that Nix does. I'd imagine this solution inherits any problems that pacman has. The Arch wiki states that "if two packages depend on the same library, upgrading only one package might also upgrade the library (as a dependency), which might then break the other package which depends on an older version of the library." (https://wiki.archlinux.org/index.php/System_maintenance https://wiki.archlinux.org/index.php/System_maintenance) This is one of the problems Nix does not have by design; in fact Nix lets you mix and match packages painlessly. This also doesn't seem to allow unprivileged users to install packages, which is kind of a side benefit of using Nix. Docker-esque solutions' issues with reproducibility are well known; I look at https://godarch.com/concepts/images/ https://godarch.com/concepts/images/, particularly how packages are installed: #!/usr/bin/env bash pacman -S steam --noconfirm and I see the same issues that https://blog.wearewizards.io/why-docker-is-not-the-answer-to-reproducible-research-and-why-nix-may-be https://blog.wearewizards.io/why-docker-is-not-the-answer-to... warns of. Heck the author even admits this is the case in an adjacent comment: "I want a machine that can be declared and rebuilt deterministically (at least semi-deterministically, rolling distro and all)" (emphasis mine). Also, frankly, I don't want to run my personal computer like a server, with complete immutability and the need to build fat image files every time I want to try out an additional program. That seems to me like a workflow that's better suited for servers where spending a few minutes for a deploy isn't a blocking operation, and where stateless service design is considered best practice.

lukego 9y ago

> Rarely used packages go unmaintained. I have a related pain-point. I want to maintain nix packages on their own long-lived branches. I also want to base these branches on the latest stable release rather than unstable. This would require upstream nixpkgs to treat my package branches as equal peers and to pull their changes with 'git merge' like in the Linux kernel workflow. Status quo seems to be that upstream expects people to work directly on the unstable branch and to make contributions using short-lived topic branches that can be rebased at any time. I spent a lot of time packaging Pharo Smalltalk for nixpkgs but I found it too complicated to stay in sync with upstream and so I ended up orphaning that package and redoing it on a downstream overlay repo that insulates me from the upstream nixpkgs workflow. This was discussed a bit over at https://github.com/NixOS/nixpkgs/issues/27312 https://github.com/NixOS/nixpkgs/issues/27312 but perhaps didn't get enough visibility because I also stubbornly prefer to work on Github and don't follow the mailing list.

Ericson2314 9y ago

> Poor CLI. Did you even read the OP? Nix 2.0 has begun to fix this as one of its highest priorities.

grantwu 9y ago
Did you even read my comment? I acknowledged that.
- Ericson2314 9y ago
  My bad. It is at the end of that.