multiple packages for multiple executables?

[peterbecich]

My understanding of the example https://github.com/Platonic-Systems/purescript-multi-nix/tree/master https://github.com/srid/haskell-multi-nix is that it shows how to package multiple *.cabal files and one cabal.project with one haskell-flake.

For a project with only one *.cabal file, with:

executable foo
  ...
executable bar

I believe haskell-flake will produce a package for foo.

How can I make packages for both? Thanks

[shivaraj-bh]

nix build .#foo works, nix build .#bar should fail. But both nix run .#foo and nix run .#bar should run.

Why?

Flake outputs’ packages exported by haskell-flake comes from package output of the function (See 1 and 2):

haskell-flake/nix/modules/project/outputs.nix

Lines 93 to 109 in 7252929

	buildPackageInfo = name: value: rec {
	package = finalPackages.${name};
	exes =
	lib.listToAttrs
	(map
	(exe:
	lib.nameValuePair exe ({
	program = "${lib.getBin package}/bin/${exe}";
	meta.description =
	if lib.hasAttrByPath [ "meta" "description" ] package
	then "${if exe != name then "[${exe}] " else ""}${package.meta.description}"
	else "Executable ${if exe != name then "${exe} from " else "for "}package ${name}";
	})
	)
	value.cabal.executables
	);
	};

All the other executables, including foo, in your cabal file are stored in exes of buildPackageInfo, which are exported in flake apps:

haskell-flake/nix/modules/project/outputs.nix

Lines 123 to 126 in 7252929

	apps =
	mkMergeHandlingEmpty
	(lib.mapAttrsToList (_: packageInfo: packageInfo.exes) config.outputs.packages);
	};

@srid any reason why the exes are not part of Flake outputs’ packages?

[srid]

@srid any reason why the exes are not part of Flake outputs’ packages?

@peterbecich What is the larger (original) use case? Is there a repro? What was expected? What is the actual case? Starting from that would be beneficial to address this.

[peterbecich]

@shivaraj-bh , @srid , you are both correct, thank you. I overlooked the apps.

A repro is https://github.com/haskell/hackage-server.
This has in a single cabal file:

executable hackage-server
...
executable hackage-mirror
...
executable hackage-build
...
executable hackage-import
...

Those are runnable in haskell-flake:

$ nix run .#hackage-server
no command given (try --help)

$ nix run .#hackage-mirror
hackage-mirror: Expected path to a config file.
See hackage-mirror --help for details and an example.

$ nix run .#hackage-build 
Usage: hackage-build init URL [auxiliary URLs] [options]
       hackage-build build [packages] [options]

(nix run .#hackage-import fails for some reason)

I was confused by the failure of nix build ... as you noted @shivaraj-bh , and also the absence of these executables in nix flake show packages. These executables are listed in apps:

$ nix flake show            
...
├───apps
...
│   └───x86_64-linux
│       ├───default: app
│       ├───hackage-build: app
│       ├───hackage-import: app
│       ├───hackage-mirror: app
│       ├───hackage-server: app
│       └───mirror-hackage-server: app
...
└───packages
     ....
    └───x86_64-linux
        ├───default: package 'hackage-server-0.5.1'
        └───hackage-server: package 'hackage-server-0.5.1'

[srid]

https://github.com/Platonic-Systems/purescript-multi-nix/tree/master

This repo has no Haskell packages. Did you mean to link to https://github.com/srid/haskell-flake https://github.com/srid/haskell-multi-nix?

In any case, for the use-case mentioned above - I'd normally expect the main cabal package to have both executables, i.e., $(nix build .#<name>)/bin/{foo,bar} should both exist.

[peterbecich]

Whoops, wrong link. I meant https://github.com/srid/haskell-multi-nix Responding above

[roberth]

haskell-flake wraps the Nixpkgs Haskell infrastructure, based on cabal2nix, which produces one derivation per package.

haskell.nix implements a derivation per component but is slow to evaluate unless workarounds are applied. Those workarounds could perhaps be facilitated by a flake-parts module, but I am not sufficiently familiar with that Haskell integration, so I was unable to validate my mediocre attempt to package it for flake-parts against a baseline UX.

I'm happy to use a conceptually simpler integration like this one instead, even if the build is less fine grained.