User experience issues

[domenkozar]

I've heard so many complaints around UX that I'll start collecting them. I'll maintain a list of possible concrete improvements/complaints/issues here.

• two names for a package: attribute name and package name (-A flag vs. default behavior)
• more informative errors Changes to make Nix output more informative errors #612
• Unclosed curly bracket fails the parser
• nix-build --check fails if derivation doesn't exist already
• eliminate the need for https://nixos.org/wiki/Error_Messages
• nix-channel --update should have a more clear message when no channels are configured: 0 channels updated
• nix-env -qa should print something in case it fails to find packages. Where it looked for packages and that they're not there.

[dredozubov]

For starters, i feel like haskell infrastructure commands are too verbose(-A and such). It can be dealt with with a meta cli-flags like --haskell or --haskell-ng, consolidating all the stuff like -f "<nixpkgs>" -A haskellPackages.(i may be a little rusty on details, it's been a while). I feel like it may be compressed to something like nix-env -i package-name --haskell --compiler=7.8.

Also it's a minor thing, but i find subcommands(something in the lines of nix install instead of more emerge-like nix-env -i) much more easier to use. You can usually introspect your options with subcommands and --help, for example. You type nix --help and get all the options with descriptions(build, install, shell, instantiate, store etc), then you type nix build --help and get all the options and subcommands for build. All the tools are distributed as a bundle, right? So it can be done with a wrappers or something.

[domenkozar]

Would you feel having a basic tutorial for such caveats and most common flags would help?

[Ericson2314]

I've voiced this elsewhere, but I'd be for nix having no special handling of package names, and then probably move them to meta too. Everything it does with them I view as broken or at least sketchy.

(e.g. update should really remember what expression was used for the build and substitute new nixpkgs for old nixpkgs---remembering attribute path and using that is a special case.)

[Ericson2314]

Hell, I'd even deprecate user imperative pkg management and just have like a ~/config/env.nix. Then update just becomes rebuild.

[domenkozar]

@Ericson2314 for imperative package management it's problematic if attribute name changes. But same is true for package names.

[domenkozar]

@Ericson2314 +1 from me for removing imperative package management.

[Ericson2314]

Sure, and if the attribute path changed, there's probably been enough of a refactor so what that one wanted before doesn't quite map to what's there now.

Basically I find much of nix-env half-assed. It tries to make things easier/familiar but since it doesn't quite realize those goals, it backfires. The correct way to have a good beginner UX is probably a GUI that edits system and per-user configuration files, which warns and doesn't change things if it sees an abstraction that it can't understand.

[dredozubov]

@domenkozar I feel like UX is hard to use(and i use plenty of CLI tools every day of my life), lots of concepts unique to nix are partially to blame for this. As a user, i don't feel a way to anchor some nix commands to the things i've used, so i feel that some work should be done on UX instead of extensive documentation of the current state. As a beginner i want to be introduced to the new concepts gradually, so when i have to type 5 or more options to the every command i use from the get-go, it's getting hard to grasp. What i'm trying to say is: cli UX should introduce new users to the concepts of nix, not scare them away: links to the relevant documentation can be added to the error output. "you're trying to do something weird by calling this command this way, this tutorial may be of help to you: "

[copumpkin]

I doubt people actually want a GUI though. The target audience is people
who are used to other package manager UIs, not GUI folks. Only satisfying
the latter seems like it'll turn away many potentially interested people.

On Fri, Nov 6, 2015 at 12:41 PM, John Ericson [email protected]
wrote:

Sure, and if the attribute path changed, there's probably been enough of a
refactor so what that one wanted before doesn't quite map to what's there
now.

Basically I find much of nix-env half-assed. It tries to make things
easier/familiar but since it doesn't quite realize those goals, it
backfires. The correct way to have a beginner UX is probably a GUI that
edits system and per-user configuration files, which warns/does nothing if
it sees an abstraction that it can't understand.

—
Reply to this email directly or view it on GitHub
#684 (comment).

[dredozubov]

@copumpkin aren't the issue about command-line UX - the "porcelain" part of it?

[rened]

+1 for making it purely declarative. I think it would make things clearer / easier for newcomers like me.

also, removing channels and sticking to a simple nixpkgs repo with branches as described in http://anderspapitto.com/posts/2015-11-01-nixos-with-local-nixpkgs-checkout.html is much easier to grok, I believe

[Ericson2314]

I guess I felt mock-imperative GUI and declarative expr language were good extremes to try to satisfy the broadest audience, but fair point traditional sysadmins would probably be lost in the gap between those too.

GUI and/or CLI for "mock imperative" management by editing and rebuilding config files sounds good to me.

[copumpkin]

@dredozubov I was responding to @Ericson2314's suggestion to replace nix-env with a GUI

[copumpkin]

@rened channels seem like a great concept to me. Part of the UX could probably be improved, but the concept seems pretty solid. Any particular reason you want to kill them altogether?

[dredozubov]

@rened I remember i was very frustrated when i tried to add a channel, i had no idea where to get the url for it - still have no clue how to look it up. Had to go to the IRC, then the bunch of wizards threw some incantations at me.

[Ericson2314]

@rened @copumpkin I have faith between using branches as the source of truth on channels, and copumpkin's ideas in #520 that there is a way to dramatically simplify the current implementation of channels.

[rened]

@copumpkin Basically the first thing I tried was to overlay/add/mix the unstable channel with custom packages. For a git repo with an "unstable" upstream branch I would know what to do out of the box, simply add my expression where I want them. Updating becomes a simple rebase.

[Ericson2314]

Impure expression that is periodically/manually re-evaluated can grab latest commit hash from channel branch. Boom!

[rened]

Further suggestion / wish: an install script for non-/nix installs, as those are very tricky to get working when following the wiki instructions. I am currently trying to come up with an install script (gist) for that usecase. This might make a great nixcon hack project.

[lucabrunox]

+1 for IMPERATIVE management... I don't want to update chromium because I only want to update tmux. Then chromium doesn't build for some reason, and I cannot update tmux. But no problem I can reimplement it by myself.

Being declarative is not the solution to the whole world of problems. Yet, the current nix-env command ALREADY has the possibility to use nix-env declaratively, see: https://nixos.org/wiki/FAQ#How_can_I_manage_software_with_nix-env_like_with_configuration.nix.3F and it's quite friendly already.

Also DO NOT hardcode nixpkgs stuff into nix-env, ever. It's a low-level tool, please create higher-level commands and perhaps make them the default for installations, like nox tried to do somehow.

[Ericson2314]

@lethalman I acknowledge the need (though keep in mind dependency duplication bloat), but I don't think imperative is the best/only solution for that.

We should really keep channels around for all gc roots. Say there was a way to update the channel so that it did this to one's config:

let todayPkgs = ...;
    yesterdayPkgs = ...;

Then one can decide what they want to rebuild or not pkg by pkg, declaritively.

This is related to the general issue of channel updates and generation rollback not being friends.

[teh]

• Following and updating the unstable channel means I have 60G of /nix/store with slightly different dependency library versions. Some form of consolidation would be useful (think apt-get dist-upgrade)
• manually need to set PYTHONPATH etc. for user profiles
• nix-env -qa is fairly slow (5 seconds on fast machine)
• curl output from downloading is too verbose, I only care about 1) it's still running or 2) it's broken. I like what git is doing which is silent initially but it sth takes too long it shows progress.

I'd also like to see ecosystem-specific commands (venv-haskell, venv-python, ...) with a nicer UI but I tried a few times and couldn't quite get something that felt right.

[spwhitt]

nix-env and nix-shell should have a consistent interface. They should both support flags like -f, they should look up package attribute names using the same method (nix-env -iA nixos.figlet but nix-shell -p figlet? This is confusing.)

Attribute names should be set up the same on nixos and non-nixos systems by default. Currently, on nixos attributes are nixos.<name> but on OSX it's nixpkgs.<name>. Obviously this can be changed in ~/.nix-defexpr, but new users don't want to have to know about this - consistency is good.

There are too many ~/.nix* directories.

[nbp]

I like and use both imperative and declarative, with different goals.

I think one of the major drawback of nix is that it has commands which are not straightforward. People expect to have install, update, upgrade, remove, source commands:

• nix-channel is currently pulling latest changes of nixpkgs, while ensuring that there is a binary cache associated with the packages. channel might have been a good name, but it does not match users expectations. I think something more in the lines of nix remote add nixos https://… would make this feel a bit more like git remote and might help people understand what is going on. (registering remote source of packages).
• nix-channel --update, should be renamed something like nix update <remote>.
• -i & -e are not obvious to first users, I saw a few new users trying to type nix install foo. I think this should become our future command line, and we should support use case such as: nix uninstall foo, nix install-expr <remote>.git.gitFull, nix install /nix/store/abcd…-foo-1.2
• nix-build should just be renamed nix build
• Currently on other distribution you are able to fetch the sources, and the recipe, current nix has no way to improve the discoverability of Nixpkgs, we could provide commands such as nix source [--recursive] <package> and nix recipe <package>.
• nix-shell can be renamed nix shell.
• nix-instantiate should be renamed nix eval.
• nix-store has too many options, which are nice, but not easy to remember. We should definitely separate most of these and split them into separated commands, such as nix build (realize), nix graph [--list|--tree|--dot] [<package>|<file>]
• nix search which goes to an optimized version of nix-env -qa for which we can effectively build an index after each update of the remotes.
• …

[vcunat]

• I much identify with Lethalman's comment.
• I expect some suggestions will come from the NixCon talk of @garbas.
• Discussing details of the various issues/solutions inside this (single) thread is probably no good. That will typically be better done in per-issue threads, I believe.

[ktosiek]

nix-shell could use some love too:

• mixing the "package's build environment" and -p would be useful for debugging (like adding ipdb/ipython to a python package env).
• nix-shell inside nix-shell breaks PS1 and readline (but that's more like a bug than UI change :-)).
• persistent shells are hard to use (and adding arguments to the mix makes it even worse).

[mmerickel]

As a new user I'm still confused on the inconsistencies between nix-env and nix-shell when naming packages. For example, nix-shell -p python27Packages.pyramid works fine, but nix-shell -p nixpkgs.python27Packages.pyramid does not work. However nix-env -qaP '.*pyramid.*' tells me the package path is nixpkgs.python27Packages.pyramid. Similarly pythonPackages does not show up in nix-env -qaP however it apparently works in nix-shell -p pythonPackages.pyramid.

These things have been very confusing for me when just getting started playing around. The examples show nix-env -qa but when I see python2.7-pyramid and spend a while trying to run nix-shell -p python2.7-pyramid-1.5.7 and having no success it's pretty frustrating.

Hiding the package names and focusing on paths would be a great start, but also the inconsistency between the nixpkgs prefix in certain places I still don't understand.

[vcunat]

Well, these two might be more about missing documentation:

• The prefix is the name you give to the channel (you can add multiple channels).
• nix-env deduplicates (some of) the occurrences, so you don't see all.

[mmerickel]

@vcunat The name of the channel is nixpkgs. The issue is nix-env and nix-shell do not seem to parse/use it similarly.

~❯ nix-channel --list
nixpkgs https://nixos.org/channels/nixpkgs-unstable

[vyp]

what about nix-env -i <package-a> -e <package-b>, would that be nix install <package-a> uninstall <package-b>? because i think the latter looks much uglier and harder to read than the former.

[vyp]

@garbas I don't think the cli should change just for those who don't read the manual at all before running commands. I find that rather ridiculous, no one should run a command they don't understand. Maybe people expect that, but nix should not remove functionality because of it. Conventions are good though, e.g. nearly all commands have --help and --version, which is great.

[et4te]

The error message: " should have SHA256 X instead of Y" is confusing since this can be interpreted to mean that in order for Nix to build the package it should have SHA256 X, when e.g in the case where fetching from an updated git repo the correct SHA is actually Y. Something more explicit / clearer would be great.

[vcunat]

Something more explicit / clearer would be great.

@et4te: perhaps suggest some (supposedly) better formulation. I can't imagine it. BTW, in nixpkgs we consider it a bug to fetch sources that change.

[et4te]

Nix expects package to have SHA256 X but the derivation failed as a consequence of it being Y ?

[vcunat]

Thanks, @peti has submitted a PR for this #707.

[tokudan]

A UX issue I'm having a lot of trouble with is adding custom packages. I managed to get burp into nixpkgs unstable, but how do I actually install it on my nixos-15.09 system?
I expected to be able to drop the package directory from nixos-unstable into something like /etc/nixos/pkgs/burp, but so far I haven't been able to find any nix expression that successfully uses that package.
All information I've seen seems to assume I want to use "nix-env -i burp" or similar commands to install it, but this imperative management is exactly what I wanted to avoid by using nixos.
So basically my suggestion is:

• Support a local "nixpkgs" out of the box, preferably in /etc/nixos/pkgs or similar

[vcunat]

@tokudan: I picked the new packages to 15.09 in NixOS/nixpkgs@28e333d60fd.

[tokudan]

I used burp only as an example. My main issue is that for a newcomer it's really complicated to get a random software into his/her own nixos system, fully integrated into /etc/nixos/configuration.nix.
Suppose as a new user I've finished installing my base nixos system. Then I see that the software whatever-3.2.1 is not available in nixpks, but I'm used to it and thus want to integrate it into my own nixos configuration.nix. I'm able to create pkgs/tools/backup/whatever/default.nix using one of the other software entries and the wiki to guide me. It builds and installs through nix-env and works in my environment.
To ensure that i just need the contents of /etc/nixos in case my hdd dies, I want to put the whatever/default.nix in there. And that's where I'm completely lost. Apparently it's not enough to throw it into /etc/nixos/pkgs/whatever/default.nix and just add "whatever" to my system packages.

Including it through imports causes errors about function arguments that I don't really understand.

Since the time I've written the burp/default.nix I've used google a lot, but all descriptions I've found either were for getting the packages into github NixOS/nixpkgs (which is important, but not suitable for every software package) or threw some error on me that I wasn't able to resolve yet.
It's obviously a steep learning curve that I haven't managed yet, but I would have expected that I can just throw my whatever/default.nix into for example /etc/nixos/pkgs/whatever/default.nix and then use a clearly documented way to include that package into my configuration.nix.
If it's not possible (or easy) to use environment.systemPackages for that, why not have environment.localPackages and have it look in /etc/nixos/pkgs (or a configurable path) by default?

[vcunat]

I'm afraid such general threads will soon become unreadable. Perhaps it's better to create separate issues from outstanding problems and e.g. add a UX label.

@tokudan, this should work well enough, though I've never used anything like it:

{ # somewhere in configuration.nix
  systemPackages = [ (pkgs.callPackage /your/path/to/burp.nix {}) ];  
}

Another way is to add it to packageOverrides, but in the case of burp you don't need to override any (existing) package.

Including it through imports causes errors about function arguments that I don't really understand.

Packages are functions (from their dependencies to the resulting paths). That's also why "just adding" some package.nix files isn't a full specification of what you want.

[dbeecham]

@vyp I sort of think it should. I'm thinking of all those times I've written "git remote list"/"git remote delete", or having to look up the manual for dpkg (again) to find out how to list files owned by a certain package, or looking up 'test' to see how you tested for integer equality.

It's not that we don't read the manual, but compared to "nix-env -qa pkg" - "nix search pkg" is easier to remember, friendlier, more intuitive, pretty, and generally more 'likeable'.

[vyp]

@dbeecham I still think it's "ridiculous" as I said earlier to run commands without knowing what they do. I was slightly wary of following pre-existing package manager cli conventions because nix is special.

However, now that I've actually used nix a lot more, I agree that the cli could probably be overhauled as @garbas said in his talk. Time to time on irc, I see people asking for what would seem like pretty basic questions about the cli, but I realise that for a newcomer it is probably bit of strange interface (I actually found myself in a lot of those situations too). At the end of the day, I'm all for making things easier to remember => productivity boosts all round. (edit: also, it should help more with world domination hopefully)

[vcunat]

@domenkozar: the third task can be checked-off.

[domenkozar]

@vcunat done. I do plan to go trough this issue and make a proper list. If someone is faster, I won't complain.

[edolstra]

I've made a design for a 3-letter Nix UI replacement: https://gist.github.com/edolstra/efcadfd240c2d8906348. Comments welcome!

[copumpkin]

@edolstra awesome, thanks! I left some comments on the gist

[drewm1980]

I was unable to get NixOS to boot at all after spending a whole evening fighting with EFI and messing around with partitions and boot flags. This sort of thing was a fun hobby in 1998, but these days people expect a linux distro to be capable of installing itself after saying "yes" to a bunch of reasonable defaults.

Thanks so much for your hard work, and I look forward to trying nixos again after seeing some installer related news!

[peti]

Closing this ticket because there hasn't been any substantive activity for 2+ years.

[joepie91]

Not sure why lack of activity would be a reason for closing the issue. This is even specifically meant to be a long-running thread for collecting UX issues (per the description in the first post), and unless an issue is either resolved or declared invalid, I don't think it should be closed at all.

If the issues have been resolved (eg. by the Nix 2.0 interface), then the closure notice should at least include information on how/where things have been solved or made obsolete. Right now, it's totally unclear what the status of this ticket is.

This kind of "close issues when they go quiet" policy - which unfortunately seems to be getting more and more popular lately, in many projects - just results in a revolving door of tickets being reopened about the same issue over and over again, but always without the previously collected context and feedback, and without the long-running issues ever getting fully fixed (because they take longer to fix than a ticket can stay open for).

It's a really, really bad idea. I certainly hope it isn't the new nixpkgs-wide nix-wide policy.

[domenkozar]

It's also not clear to me why closing issues really helps in any way.

[coretemp]

Can we reopen this?

[edolstra]

I think it's better to open individual issues and tag them with the UX label.

[joepie91]

I'm not sure that that's a good approach. UX aspects are a lot more interconnected than logic bugs, and addressing each UX issue in its own thread will likely just lead to duplication of discussion and solutions that don't integrate well with solutions to other UX issues, because the desired user experience as a whole has not been considered.