On Tue, Sep 9, 2014 at 8:16 PM, Mateusz Kowalczyk <[email protected]> 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
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
