[candiodari]

Maybe it's just me but I hate this option. Are we really, really trying to optimize the downloading of source code ? All 5 megabytes of it ? Why would you do that ?

I regularly find myself in a position that this system would make impossible: I need a few custom changes in public available libraries. An extra method. A bugfix. What have you. This makes that impossible using the default method.

What we want is consistent builds. That means a build that happens, with the same source, with the same ... every time, always, on everybody's workstation.

[pokstad]

Go modules still allow for changes to local copies. You are not required to use a proxy to use modules. Also, you can always fork a public project and use a replace statement in a module to redirect an import path to your customized module. Check out this related tool: https://github.com/rogpeppe/gohack

[candiodari]

And another configuration file that you (and all tools) need to know about pointing at yet another global directory (global for all your projects). That override file, of course, does have to be in your project folder and is yet another thing to take into account.

If I want to share things, I am aware of links in filesystems, thank you very much Go authors. "go.mod" overrides ... I wish golang did not try to solve yet another non-problem badly.

[icholy]

Vendoring will still be supported.

[calcifer]

How will that work with modules though? As in, how do you vendor a single library (that you want to make a fix to) while still building with module support? Right now, "module mode" is mutually exclusive with "vendor mode" and I don't think there are any plans to change that.

[EdiX]

> Right now, "module mode" is mutually exclusive with "vendor mode" and I don't think there are any plans to change that.

This is not true. If you pass -mod=vendor, or place it in $GOFLAGS, go will build something outside of GOPATH, in module mode, using the vendor directory exclusively. I wish it was the default, but only because it encourages people to not use vendor directories (which is a bad habit), not because it can't be worked around easily.

[calcifer]

> in module mode, using the vendor directory exclusively

But that's not what I'm asking. I want "go build" (with some flags) to use my fork (vendored if needed) for one library, and pick up all other dependencies from the module cache as usual. How do I that?

Because this is already possible in a vendor-only world; I just edit the code in vendor.

[EdiX]

You check out the dependency you want to change and add a replace directive in go.mod. Either a temporary one to a file system path or a permanent one to a forked repository.

[candiodari]

Why are vendor directories a bad habit ? There just shouldn't be any GOPATH at all as far as I'm concerned.

Look in /usr/include. There you can see what's wrong with GOPATH, 5 years in the future. Now try installing 2 different versions of libraries.

I'll wait.

[EdiX]

> Why are vendor directories a bad habit ?

They aren't, not having them is.

[programd]

I have to violently agree with this (consistent builds).

All the infrastructure with index, notary, mirror, etc. is nice, but at the end of the day you have to fetch some external code, verify it, lock it down in some vendor directory, and check it into your own backed up repo. Everything else is fluff.

If you're not doing this you're dancing with the devil and one day when you need to tweak some module or fix some bug, and the remote source is long gone, you will rue the day you depended on anything except your own source storage. And it will be 3 AM on Saturday, in some dismal server room, with no outside Internet connection, your customers screaming at you, and your phone battery dying, because Murphy's law.

For the purposes of software builds just pretend the rest of the Internet does not exist. Vendor everything, all the time, everywhere, and trust nothing.

[superbaconman]

Yeah. I feel like the modules work for the most part, but as soon as I want to develop cross project I have issues. Do I use the replace directive in my go.mod file? That's just gonna lead to merge issues whenever someone bumps a version number. Do I build using the vendor method that sounds like it's going to be ripped out at some point? How does my dev repo even get linked into that?

This whole gopath-less thing is a bit confusing to me. I wish the 'how to use packages' stuff was clearer.