You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
can't load package: package cmd/yggdrasil: cannot find package "." in:
/nix/store/zvi4wy0kzh3iz7db7dl7p7dk1rqf7frj-go-1.12.6/share/go/src/cmd/yggdrasil
builder for '/nix/store/3v6yv2gf73x9avw5j5jbmg3iksvwci0x-yggdrasil-0.3.5.drv' failed with exit code 1
error: build of '/nix/store/3v6yv2gf73x9avw5j5jbmg3iksvwci0x-yggdrasil-0.3.5.drv' failed
Notes:
If you reverse the order of the subPackages then the error message will refer to cmd/yggdrasilctl instead. If you include only one child package in subPackages, the derivation will build, and this:
The problem is that the echo "./$subPackages" line in getGoDirs in pkgs/development/go-modules/generic/default.nix only adds the "./" onto the first item in the list.
I'd like also to suggest a change to the description for subPackages in the manual, since I found the existing one confusing. "subPackages tells the builder which child packages to build" would be clearer than "subPackages limits the builder from building child packages that have not been listed." Also, since the value in the example for subPackages is [ "." ], it would be nice to have an additional sentence describing what that means and why you would want to use that instead of leaving subPackages unspecified.
Issue description
When more than one child package is given in subPackages, buildGoModule fails to build the second one.
Steps to reproduce
Build this derivation:
Result:
Notes:
If you reverse the order of the subPackages then the error message will refer to cmd/yggdrasilctl instead. If you include only one child package in subPackages, the derivation will build, and this:
makes the derivation build correctly.
The problem is that the
echo "./$subPackages"
line ingetGoDirs
inpkgs/development/go-modules/generic/default.nix
only adds the"./"
onto the first item in the list.I'd like also to suggest a change to the description for subPackages in the manual, since I found the existing one confusing. "
subPackages
tells the builder which child packages to build" would be clearer than "subPackages
limits the builder from building child packages that have not been listed." Also, since the value in the example for subPackages is[ "." ]
, it would be nice to have an additional sentence describing what that means and why you would want to use that instead of leaving subPackages unspecified.Technical details
The text was updated successfully, but these errors were encountered: