I have a problem where a dependency of the “go” package is shadowing a system command. The command in question is xcodebuild, part of Xcode. The xcodebuild installed via Xcode is version 14.2, but the version installed as part of the “go” package is 9.4.1, making it about five years out of date.
$ xcodebuild -version
Build version 14C18
$ nix-shell -p go
[nix-shell:/tmp]$ xcodebuild -version
Build version 17E189
I used nix-shell -p here just for clarity, in reality I am using nix-shell with a shell.nix file. I tried to define an alias like you said, but because xcodebuild is actually called by another tool, not via the shell, it did not solve the problem.
I haven’t learned much nix yet, but it looks like the “go” derivation takes an “xcbuild” parameter (here). Is it possible to override it with an empty derivation, so that the xcodebuild binary is never installed? Here is my shell.nix:
When I override its xcbuild attribute, the go derivation no longer installs a precompiled binary - it compiles from scratch, which is not ideal. It seems odd that the go derivation installs xcodebuild - which is presumably used only to build go - when the go binary is supplied precompiled.
It’s not pretty, but the solution I currently have is to remove the xcodebuild bin directory from the PATH:
Well, you changed the propagated build inputs of the Go derivation. By the rules of nix this forces a rebuild of the derivation and thus a build of Go from source.
Further, xcodebuild is not only used for Go itself. It is in the propagated build inputs. That means it is actively provided to any packages using Go. (You can grep through nixpkgs to find quite a few.)
Altogether, the behavior you observed is correct.
That said, if your workaround server your purpose: That is perfectly fine, but beware of any issues arising from impurity.
I can’t see why a package using Go would expect Go to provide the xcodebuild command. How do you grep through nixpkgs? What packages did you find that seemed to be depending on xcbuild as a propagated build input?
Because It is a random requirement made by apple that X-Code is used in the build. To make that easier Go (as many other buildtools) propagate it, then a random go package does not need to remember to do so.