[Nix-dev] Newbie experiences with NixOS

[Alexander Kjeldaas]

On Tue, Sep 9, 2014 at 8:16 PM, Mateusz Kowalczyk <fuuzetsu at fuuzetsu.co.uk>
wrote:

> On 09/09/2014 06:24 PM, Gergö Barany wrote:
> > Hi everyone,
>
> [...]

> >
> > When running "nixos-rebuild build" on this, it failed with:
> > error: cannot coerce a set to a string, at
> /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/lib/types.nix:98:79
> >
> > Needless to say, I never touched that file. If I recall correctly,
> > specifying a *concrete* ghc package name did work. Using a generic name
> > imperatively worked: "nix-env -i ghc" selects a derivation automagically
> and
> > installs it.
>
> The error message sucks but if you have some experience (which as you
> say, you don't) it's simple to guess what's going on. There are two
> things to answer here.
>
> 1. ‘nix-env -i ghc’ worked because ‘-i’ resolves by package name, not an
> attribute name. It more-or-less makes a rough guess at what you mean by
> ‘ghc’. Using the attirbute names in preferable because it's not
> ambiguous. Notably, systemPackages and just about everything except
> ‘nix-env -i’ uses these attribute names. You can query attribute names
> with ‘nix-env -qaP’. This way, you'd quickly find out that you need to
> specify where GHC comes from: ‘haskellPackages_ghc783.ghc’ or even just
> ‘haskellPackages.ghc’ would work for you. It just happens so that the
> ‘ghc’ attribute points to a set of things which is where the error is
> coming from. Unofficially, it seems that using ‘-i’ is discouraged. I
> think we should aim to change our documentation and wiki to teach about
> ‘-iA’ instead.
>

Just pointing out the meta-problem here, which is related to the nix
language being "too powerful".

The expected behavior here is that when an attribute does not resolve
properly, the message:
"unknown attribute %s, run nix-env -qaP to find valid attributes" is shown
to the user.

In general, an "exception" mechanism that catches and displays useful tips
when attributes do not resolve properly, or similar issues appear is
important for any language that tries to expose a higher-level DSL.
Otherwise the implementation details shine through and it will never be
user friendly.

C++ template meta-programming and lens error messages are other examples of
the same type of problem.  A proper abstraction must both exist in the
language, and for the error handling.

Alexander
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20140909/24e3396f/attachment-0001.html