BTW, my current workflow is this now:

• setup the environment using GOPATH
• create an alias for the go command: alias gomod='GO111MODULE=on go mod'
• initiate with gomod init
• download deps with gomod download
• create vendor directory using gomod vendor

Everything else like build or install is done using the normal go command.

If you introduce new or delete existing dependencies in your code, name them in your go file's import statement and then run

• update deps with gomod tidy
• update vendor with gomod vendor

So far I am happy with this, because I will get to use propper dependency management, witch can be automated, does not need additional tools like dep and gives me a simple way to a clean vendor directory.

But if you drop the search-for-imports feature of the GOPATH - me fucked! :))

Hey @FredFoo, you'll need to include module paths in your import declarations. If you have a go.mod file in hlog, it should contain the line module git.private.home/Dumper/hlog, and you'll need to import that package with import "git.private.home/Dumper/hlog".

Avoid using replace directives for remapping imports. replace directives have two main uses: 1) you need to use a temporary fork of an upstream module (e.g., because you're waiting for a bug to be fixed) and 2) you want to use another module in the same repository at HEAD instead of a published version (useful for making changes in multiple modules with a single commit). In both cases, you need to import packages in replaced modules with the original import paths.

You can find more information at:

• Using Go modules
• Module wiki
• go help modules

At this point, we're not going to make significant changes to the way modules work, so I'll close this issue.

@jayconrod, that is exactly what I was afraid of!
With GOPATH for more than 8 years it was fine to use import "hlog". I have used this package in nearly a every binary I wrote. And I have a number of other packages (libraries) that also would be checked out from my internal code repo if needed. I know that some people might say I should not work like this, but I some of them smoke and I dont tell them they need to stop just to satisfy my view of the world.

What you do is telling me that I should change hundreds of import statements in hundreds of files to use modules and the dependency management. And when GOPATH goes away should becomes must or all my builds fail.

And that is because you want me to forget what was the truth yesterday - hail GOPATH! - and only accept what you say is the truth today - hail Github!. I dont understand why this must be so imperative.

Say you come up with the idea you can get rid of the PATH variable in the shell, because you can always call a binary with the full path! I would say fine, you dont have to use PATH if you type fast and love typing - use export PATH="" and you get what you want. Why in the world would there even be a thought that the PATH feature has to be dropped and EVERYONE now has to type full paths to call binaries?

I dont get it. Thinking of the wave of unnecessary work coming up I feel sick. So I am asking why? WHY? If there is a blog post or whatever that helps me understand, please point me to it!

BTW, I know its not you personally, please believe me when I say I do not want to offend you :))

Oh, and regarding the bug that I seem to have found.

Would it not hit in the same way if I use the replace statement as intended? I would perhaps also not work for subpackages - at least the information you linked to and which I read before did not state anywhere that replace is not supposed to work for subpackages in your modules. Or should modules not have subpackages at all? Did not read about that either in those documentations.

So why close it if it is probably still broken?