I agree and what i am saying is that if you expect newcomers to use this, then you need to rethink that first impression experience. I am not saying it is wrong, it just means it is not meant for newcomers to nix
4 Likes
Dumb question: Why doesn’t nix implicitly attempt the equivalent of -A first, and then move on from there? Are there backwards compatibility concerns?
That being said, I wholeheartedly agree with some of the comments in the thread about nix being difficult to use, especially the fellow who was talking about trying to adopt it for use at a company. I very much feel that nix’s achilles heel right now is usability, to a “hasn’t even heard of leg day” level. This may seem harsh, but I say this having used nix for ~2-3 years and still struggling with things that seem like they should be easy, like creating a python environment with packages from pypi. Or having to reinstall nix on macOS because my install got clobbered by company chef. And this is just stuff from the last month.
The issue that I see is that nix is incredibly flexible and capable. But it’s also inconsistent in how you specify things and the knowledge is often obscure - often requiring you to dig into the source code. And that is the point where you’ve definitely lost nearly all potential users.
As far as nix-env flow specifically is concerned, imho the tool should actually be expanded such that whatever ‘environment’ you are in - whether it’s the user environment, or one you’ve entered with nix-shell, it will allow you to introspect over things specified in the declarative config as well as things you’ve added with the imperative config. In that case, I would probably have it by default operate ephemerally, unless given a --persistent option, in which case it would add it to your declarative config. Where this option isn’t available, it would either be read-only or would generate an error when persistence is attempted.
This moves it into the position of allowing you to introspect your current packages without delving into the source. Right now the presumption I think is that the user wrote the nix config - but that wouldn’t be the case at large enterprises, which might supply all or a portion of the applications that their users use, and the users might be relatively non-technical as well.
Other things that I think would be incredibly helpful for new users would be a graphical install process for macOS that does everything for you, rather than dropping a bunch of shell commands on you and asking you questions you don’t know the answer to if you’re just starting out. And making the syntax of overrides simpler and more consistent. And also more testing of things to shift the needle from quantity of packages towards quality (ideally you’d improve both, but I realize resources are limited).
I also think nix-windows would considerably increase nix’s utility, as it would support all 3 major OSes then to some level then. And I mean this more on the level of supporting graphical applications that are currently in Chocolatey (or maybe just leveraging Chocolatey), rather than just things currently in nixpkgs. (Another speed bump: nix falls just short of seamless user experience with graphical applications on macOS due to putting things in ~/Applications rather than Applications, so they aren’t findable with search as they should be. Although this is under the jurisdiction of nix-darwin AFAIK).
I’m not really sure if there’s a scope issue here - the question I’ve been somewhat afraid to ask is if nix is intended to only work for developers. I’d rather it be a general-purpose cross-OS user, system, and internal software package manager. I think it comes closer to a universal package and environment manager than any other package manager I’m currently aware of (well, I think brew has support for Linux, but I’m not sure how good it is). Even if it is, I think there’s room right now for a frontend that could automate the most common “new user” tasks (install software, configure software preferences) that would allow the majority of potential users to never have to dig into the source unless a package wasn’t working (at which point they’d probably ask for help).
One question I repeatedly got asked when I tried to use it at a company for internal software was “Why not use docker?” At the time, docker didn’t work with macOS as a guest OS. However, the reason for that was that it was simpler and faster to write a Dockerfile specifying things with shell commands than to figure out what syntax in nix you needed to use. It was also hard for people to grasp what nix was (it’s an OS…or a package manager…or a build system…or some kind of pseudo-containerization thing). Or what benefit it provided, because the costs were immediately apparent (learning curve) but the benefits were long-term (reproducible build environments on developer and CI and being able to quickly compose environments with internal packages).
Anyway, I’ve rambled on for quite a bit here, but this touched upon a topic of ‘organizing system state’ that I’ve developed some passion for after constantly transitioning between Linux, macOS, and Windows and having to go through manual steps each time. Nix seems very well-positioned technically to provide an OS and language-agnostic abstraction layer of system state, but the usability needs to go a considerable distance to make it practical for less-determined users.
4 Likes
Hello folks, interesting discussion indeed, I just wanted to quickly add my experience in the hope it adds something to it:
- just bought a MacBook Air M1 so I thought to take the chance for setting up my development environment using Nix (and eventually fade out Homebrew, if possible). This is my #1 use case for Nix and probably always will for me
- started following the official “Nix Manual” and used only
nix-env -iso far, I don’t even know what -A is supposed to do yet, I’ve not used any other Nix client so far - I’m usually ok with CLI tools so using
nix-envdoesn’t bother me much but so far tbh I wasn’t able to install many of the tools I use for my day-to-day working activity - to be honest I haven’t read any other document yet and I’m a total noob with Nix, I’d love to get to know more about it though but I’m currently confused on the next steps
2 Likes
Can you send me the list of applications or post it here? I’ve been working on a way to make it easier to add macOS applications to nix using the regular .dmg/.pkg method. I also have some applications using that method I still haven’t submitted. EG:
- carthage
- codesigndoc
- divvy
- ext4fuse (forget if this works)
- f-lux
- firefox (last I checked the current nix one doesn’t work on macOS)
- geekbench
- jlink (forget if works)
- macfuse (forget if works)
- Mountain Duck
- NRF Command Line Tools (forget if works)
- ProStudioMasters
- sentry-cli
- Signal
- Spotify
- Thinkorswim
- WeBull
- Zoom
2 Likes
6 Likes
hey @spease , sure thing. This is what I’m doing atm:
- nix-env -i go ansible slack vscode awscli2 direnv wget
- brew install firefox google-chrome telegram-desktop resilio-sync iterm2 viscosity terraform zsh-git-prompt caffeine zoom golangci-lint tor-browser
- brew install —cask docker
I can’t swear I tried all the ones currently installed via Homebrew first in Nix but for most of them I did and error was usully “unsupported arch” or similar. About Docker it looks available in Nix but I needed Docker Desktop, not only the CLI + daemon. For Terraform I needed the latest stable and it was not available at that moment.
PS I’m still confused by how applications like VSCode, Firefox and others, who provide a “download upgrade” option, behave in Nix.