Hi, there's an outline of the path forward in the Go Modules in 2019 blog post, which I encourage you to read in full. Here's an outline with the information you're looking for:

Go 1.11 (August 2018):

Go 1.11, released in August 2018, introduced preliminary support for modules. For now, module support is maintained alongside the traditional GOPATH-based mechanisms.

Go 1.12 (February 2019):

Go 1.12, scheduled for February 2019, will refine module support but still leave it in auto mode by default.

Go 1.13 (August 2019):

Our aim is for Go 1.13, scheduled for August 2019, to enable module mode by default (that is, to change the default from auto to on) and deprecate GOPATH mode.

So yes: the current plan is to deprecate GOPATH in Go 1.13 (scheduled for August 2019).

If you're starting a Go project now, my suggestion is to use 1.12 (not yet officially released, but it'll happen soon and we already have a release candidate you can use), and try to use the new MODULE system.

Is there going to be support for internal packages directly, without the replace "trick"?

For example:

require internal/foo v0.0.0
replace internal/foo => ./internal/foo

It could be written as:

require ./internal/foo v0.0.0

Sadly this does not work yet, but are there any plans to support it?

Hi @ALTree,

I have a related question. When the GOPATH is deprecated (starting with Go 1.13), what about the $GOPATH/bin directory? I mean, where will the executables installed by the go install be placed? Somewhere like the /usr/local/bin?

Hi @ALTree,

I have a related question. When the GOPATH is deprecated (starting with Go 1.13), what about the $GOPATH/bin directory? I mean, where will the executables installed by the go install be placed? Somewhere like the /usr/local/bin?

Hmm yeah, and what about old go projects and go get? Where will the binaries be placed? Are we going to be able to change the destination path?

Is there going to be support for internal packages directly, without the replace "trick"?

Internal packages are already fully supported, no replacements necessary. Visibility is based on the package import path, and the internal packages can be in the same module or a different one.

(I would suggest keeping everything in the same module to the extent possible.)

When the GOPATH is deprecated (starting with Go 1.13), what about the $GOPATH/bin directory?

GOBIN will continue to work, as it does today. The GOPATH environment variable will probably outlive GOPATH-mode builds, since it also currently identifies the location of the module cache.

Thanks, @bcmills. :-)

Is there going to be support for internal packages directly, without the replace "trick"?

Internal packages are already fully supported, no replacements necessary. Visibility is based on the package import path, and the internal packages can be in the same module or a different one.

(I would suggest keeping everything in the same module to the extent possible.)

Oh, where can I read about it it more? I am currently using replaces to make it work as intended, but could not find a way to make it work without that. :/ All the things I have tried require it to be a hostname of some sort, it tries to do a HTTPS GET on it.

So my question is: is there a way to refer to a subdirectory directly, such as ./subdir/...? Because right now it says "import path does not begin with a hostname". Do I really need to have it uploaded first to be able to use a directory which is in fact part of the git repository, and the project anyway? Or do I need to continue to use replace for this kind of thing? Not even sure how I would do it because https://example.com/go/project is already a file with the necessary <meta> and https://example.com/go/project/internal/foo cannot be achieved via regular files as can't have a file and a directory with the same name simultaneously. The only solution I can think of is changing my web server config, which is not something I am planning to go, would rather use replace.

When I try to use ./internal/foo, I get "cannot find module path for ...". This was my first attempt to use internal packages + go mod without any HTTPS GET involved, but seems like the only way is by using replace. Please correct me if I am wrong.

Worth noting that I am using packages for namespaces, and organization. I have packages inside ./internal/ for this purpose, such as: ./internal/pkg1, ./internal/pkg2 and so on. It doesn't work nicely with go modules, it worked well with GOPATH. Since GOPATH is going to be deprecated, I am using modules for this purpose, but it doesn't work without replace, because it tries to resolve it as a hostname which is problematic for the aforementioned reasons. These are just meant to be simple internal packages used within the project itself, not anything outside of it, so HTTPS GET or the requirement to publish it online first to be accessible within this project makes no sense to me, it should work offline as-is. If there is no way to make it work as such, is it a possibility to add an exception for anything stuffed inside the internal/ subdirectory, or a keyword to make a requirement/module/package "internal" (therefore not perceive it as a hostname and try to resolve it, etc.) in future versions of Go?

So, "I would suggest keeping everything in the same module to the extent possible." is fine. I am using only one module, my project. It depends on internal packages, which I cannot import without adding them to go.mod as modules, i.e. I cannot use relative import paths to import those internal packages, because it says "cannot find module for path _/.../project/internal/pkg1". Putting it in go.mod and using a replace to redirect internal/pkg1 to ./internal/pkg1 does the job.

What I am trying to know is, how to import internal packages and make it work with go modules without using replace? If the aforementioned "cannot find module for path ..." when trying to import a relative path (internal package) is a bug, let me know.

@bcmills

Is there going to be support for internal packages directly, without the replace "trick"?

Internal packages are already fully supported, no replacements necessary. Visibility is based on the package import path, and the internal packages can be in the same module or a different one.

(I would suggest keeping everything in the same module to the extent possible.)

Sorry about this question but could you clarify it? What do you mean with "I have to import internal packages by full import path" ?

I have a project like so:

Working directory: /home/me
-MyProject
 -MyLocalPackage 
   local.go
 -AnotherLocalPackage
   anotherLocal.go
main.go

on go.mod I had to do:

require MyProject/MyLocalPackage
replace MyProject/MyLocalPackage => ./MyLocalPackage

and go claims:

go: parsing MyLocalPackage/go.mod: open /home/me/MyProject/MyLocalPackage/go.mod: no such file or directory
go: error loading module requirements

So it was forcing me to create go.mod files for subpackages too.

1. How can I work with local subpackages without having to add replace in the main go.mod file and not being obligated to create a go mod file inside this subpackage?

I have the same question. I did the same replace thing in ./go.mod, then I created ./MyLocalPackage/go.mod, it works as intended, the module path specified in this file doesn't seem to matter either. It can be omitted and so on.

Using replace is fine to me, but apparently there is a different way where we don't have to use it for internal packages?

Also, running go mod verify will result in internal/pkg1 v0.0.0: missing ziphash: open hash: no such file or directory, which is probably intended, but introducing a way to import internal packages (with go.mod present) would solve this. Can use a keyword such as internal, or the prefix ./ could indicate that alone, and so on.

@RenathoAzevedo https://github.com/J7mbo/go-subdirectories-with-modules

This repository seems to help, I believe. My issue was wrong module path in ./go.mod. It renders all my issues nil, the reason for HTTPS Get was that my go.mod had module https://.../proj in it, not module proj.

This is the simplest example of using subdirectories with go (which is not how the makers of go intended it to be used).

Why not? If not this, then how do you break code into multiple .go files? I really don't need to use packages, but I don't know of any other way other than putting all .go files into the project's root directory, which can get quite messy.

The original question has been answered, and I would like this thread not to turn into a big messy Q&A session about Go modules (we don't use the github issue tracker for this kind of stuff anyway).

If anyone has any more questions, please see: https://github.com/golang/go/wiki/Questions. There are a few places that are better suited for them (like the golang-nuts mailing list, or the Go forum). Thank you.

Closing here.