I've seen projects leave default.nix as is for inclusion in all-packages.nix, and instead create shell.nix to hold the (import <nixpkgs> {}).callPackage ./default.nix. Then building is done simply with nix-shell in the same folder as shell.nix.

Another option I've seen is running nix-build --eval -E '(import <nixpkgs> {}).callPackage ./default.nix on the command line.

Not sure if these are much of an improvement, but at least you don't have to rename your default.nix.

@boxofrox If we do what you describe and leave default.nix as-is, then we can't run a simple nix-build in our project and have it work. Telling people to run nix-build --eval -E '(import <nixpkgs> {}).callPackage ./default.nix is not an acceptable solution. Getting a drop-dead simple UX is crucial if we want to significantly increase adoption.

I also tend to think that requiring multiple .nix files in order to build your project with nix is a really significant obstacle. So maybe it would be better to package up your above nix-build command somewhere and make it simple to run.

I don't know what the right solution is, but I think it's really important that we figure it out and prominently document it.

I usually just write just a single default.nix as

{ nixpkgs ? import <nixpkgs> {} }:

with nixpkgs;

stdenv.mkDerivation {
  name = "foo";
  # ...
}

This is not compatible with callPackage, but it can be easily adapted if needed.

@veprbl Actually that can be made compatible with callPackage fairly easily:

{ pkgs ? import <nixpkgs> {} }:

with pkgs;

stdenv.mkDerivation {
  name = "foo";
  # ...
}

pkgs is refers to itself so it works both ways (for instance you can do pkgs.pkgs.pkgs.pkgs.hello).

Because this is documenting Nixpkgs, this should be part of Nixpkgs' docs.