I’m the author of go2port and the original author of the golang-1.0 port group.
The reasons for preferring “offline” builds have been discussed ad nauseam, but the discussions that I am aware of are dispersed across Trac, GitHub, the mailing list, etc., so it would probably be a good idea to put together a FAQ. Note that as I recall the idea of standing up a MacPorts-specific goproxy was raised and rejected. About go2port and the golang port group in particular: What you describe is *not* a failing of go.vendors per se; it *is* a somewhat common failure mode of go.vendors *as generated by go2port*. go2port implements a naive subset of go’s actual dependency resolution logic. It works well for some subset of projects that have relatively simple dependencies. It falls down in some cases, notably when depending on subpaths within a larger project, and especially when requiring different versions of said subpaths. There are some ports where the shortcomings of go.vendors-by-go2port can be manually overcome without too much trouble. I maintain terraform-ls, which is one such port. It generates go.vendors about 80% correctly, and then I go in and do some manual fixes. It’s annoying, but much better than trying to write go.vendors from scratch, and still gives all the benefits of an offline build. Then there are some ports where such manual fixups are too cumbersome, and the maintainer has chosen to forgo go.vendors and allow “online” builds. Please note that this *is* an option for you. No one is forcing you to use go.vendors (though MacPorts as a project does strongly prefer offline builds; so far my understanding is that it’s better to have an online-built port than no port at all). So I feel like saying “don’t use go2port” or “don’t use go.vendors” is not a reasonable position. It works very well for some subset of go ports: I count 481 ports using the golang port group; of these I count 230 using `go.offline_build no` (I suspect a lot of these *could* be made to work offline, but the maintainers didn’t want to deal with it). Instead of saying “don’t use it”, I would suggest: - Help make the shortcomings more apparent, so people aren’t surprised like you were - Help improve go2port to make the subset of nicely handled ports larger - Work with the golang people to make their module system more friendly for from-source package managers like MacPorts -Aaron
