nix/guix was not ignored.
There are a host of other reasons that we could happily debate for years (no thanks), but bottom line: you can't use it everywhere you can write/compile Go code.
While it's true, that you can't use nix/guix everywhere, but the ideas are orthogonal to where you can write/compile Go code.
Not looking for a debate: Why can't you use it everywhere you could write or compile Go code?
Re:Go Packaging Proposal Process
by tomjakubowski on Friday July 29, 2016 @02:30PM
(#12188872)
Nix barely supports Windows, for one thing. I don't think Go developers would consider installing cygwin just to run a broken version of Nix. And it doesn't officially support any BSDs other than OS X, I think.
Go package management needs to work with Git, Bzr, Hg, and Svn as it does today. Do you have suggestions on building a tool cross platform that works with packages in all of these that doesn't have external dependencies?
It doesn't matter where the code is stored, certainly not for nix.
I'm sorry, I don't understand. `go get` or any package manager needs to be able to fetch the code remotely. Without interacting with the external binaries would mean the Go tool would need to have custom code to retrieve the codebase and interact with the VCS metadata such as tags. Are you suggesting custom Go code for that instead of using dependencies like git?
No, git would have to be a package in the same package manager, as a build dependency. Think OS package manager, but limited to what developer needs, i.e. just software, no services, no superuser privileges, etc.
Talk about feature creep! It sounds like you want a package manager and ecosystem that can install half an OS, just so you don't have to fuss with installing git on your own...
It's going to be "half an OS" either way. But it can be nice and reliable, if you go the nix road.
More specifically, there is already a package manager and ecosystem that can install all of an OS, and you don't have to fuss with installing anything on your own. This package manager and ecosystem could subsume the problem of language-specific package managers entirely.
Personally I don't think we need yet another package manager with painful external dependencies, non-reproducible builds, conflicts, lack of rollbacks, etc. We have that with "go get". What we need is to actually solve all those thing. Make sure there are no fragile external dependencies, but everything is in the package manager, even gcc, binutils. You get the idea.