Nix: Nix 2.0: Default -f to ./default.nix when it exists

[ElvishJerricco]

I think most people use -f ./. far more than anything in NIX_PATH. This seems the much more sensible default to me.

[lheckemann]

nix build still does this AFAIU.

[ElvishJerricco]

A bare nix build with no INSTALLABLES arguments will look at ./default.nix. But if you add any argument, it will revert to NIX_PATH. This inconsistency is another reason to prefer -f ./. by default.

[edolstra]

Making it depend on whether ./default.nix exists means its behaviour depends on the contents of the current directory. So nix build nixpkgs.hello would succeed if ./default.nix doesn't exist, but would fail if it does.

[vcunat]

We had this with nix-build, but that was rather inconsistent with nix-env which is mostly used with NIX_PATH.

Maybe it will be best that devs have a shell alias/function that supplies their favorite set of arguments, e.g. nix-build -f . --keep-going

[shlevy]

IMO regardless of the current directory structure nix build shouldn't search NIX_PATH by default. I understand in e.g. nix run that you often just want to pull from nixpkgs whatever directory you happen to be in and it would be good to have easy syntax for that, but the default.nix case seems much more common for the nix build usage.

[ElvishJerricco]

Yea if we're concerned about consistency with current working directory, I'd rather just have a different syntax for using NIX_PATH and always default to ./default.nix. I understand that defaulting to NIX_PATH is much more useful for people whose primary Nix work is on contributing to nixpkgs, but I don't think this is the typical person's use case

[lheckemann]

FWIW nixpkgs isn't the only thing allowed on NIX_PATH :)

[ElvishJerricco]

Can someone explain why the current behavior is desirable over default.nix? I can't really say I understand.

[lheckemann]

Because one of the goals of nix's new interface is to be more consistent in how packages are specified in nix commands.

Selecting stuff by attr paths is extremely common, hence it makes sense to use positional arguments for attr paths. However, that means we lose (in comparison with nix-build) the ability to specify which set we want to find this path in.

We want to make installing stuff easy, and the common case for that is to install stuff from some "global" package set. I hope we can agree that -f '<nixpkgs>' is terrible for that? And I don't see package installation varying by cwd being any fun.

So by making the default expression to select from an attribute set containing NIX_PATH entries, we get both the ability to easily select from some common package sets, and the ability to select an attribute path without the pesky -A.

So in summary, the current behaviour is a consequence of the two goals: 1, having a consistent interface between nix build and the future nix install (and others), and 2, having a convenient way to install packages from the common set.

n.b. this is just my understanding of the rationale, and I'm not saying it's the One True Way.

You still have a multitude of options if the UI doesn't change from its current state:

• Add something like wd=. to NIX_PATH, and do nix build wd.foo.bar to build some sub-attr of your default.nix (tried this, it works)
• Add your projects to NIX_PATH, and build using nix build project.foo.bar
• Continue to use the old tools — nix-build etc.
• Make wrappers for the new tools, be they aliases (alias nb="nix build -f ." anyone?), more complex shell functions or fully-fledged scripts.

[ElvishJerricco]

Hm ok. I agree that having the consistent, attribute-path driven UI across all tools is good. But personally, I'm doing builds in some local nix-based project far more often than I am installing software from nixpkgs. In my (obviously biased) bubble of people, this is the common case. So I question whether the tools should be centered around installing software or building projects. With Nix as a build tool, I think the current behavior is just as surprising and annoying as the alternative would be for Nix as a package manager. So I guess it's just a matter of prioritization, unless someone can think of a solution that suits both cases equally well.

[7c6f434c]

So I guess it's just a matter of prioritization, unless someone can think of a solution that suits both cases equally well.

Currently I see nix build -f . and nix build default.nix as the most succinct approaches. Maybe nix build . should be treated like nix build -f .?

[shlevy]

I (and others whose workflows I know we'll) also do builds on some local projects much much more often than installing from a global set. More importantly IMO, I can't think of a time I've ever used nix-build with a nix path based lookup. I understand the desire for uniformity, but nix build is a very different command than nix-env or whatever the new way of installing will be.

[7c6f434c]

Hm. I do use a wrapper over nix-build that basically does what nix build now does but with --no-link — sometimes just in a shell and without using it as a nix-shell replacement. Of course, nix build would need to print the output path to be usable in that role.

[ElvishJerricco]

I've been trying to think of some good alternatives for this. A major sticking point is the inconsistency outlined in #2017. I think a good compromise would be to add a default entry to the top level attr paths. i.e. nix build default.foo.bar equates to nix build -f . foo.bar. For now, I'll be adding this to my NIX_PATH:

export NIX_PATH="default=.:release=./release.nix:$NIX_PATH"

But I think default should be there by default so that scripts can rely on it. Also, if default were available, then we could remove the inconsistency in #2017, since users could simply do nix build default.

[michaelpj]

This is a continual annoyance, and makes explaining to new people how to use the nix commands awkward.