Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: Is `GOPATH` going to be deprecated? #30329

Closed
odiferousmint opened this issue Feb 20, 2019 · 12 comments

Comments

Projects
None yet
6 participants
@odiferousmint
Copy link

commented Feb 20, 2019

Hello. I am going to create a new project but there are many ways to go about this. Is GOPATH really going to be deprecated in future versions of go? Because if so, I would not want to depend on it.

Thanks in advance!

@dmitshur dmitshur added the Question label Feb 20, 2019

@ALTree

This comment has been minimized.

Copy link
Member

commented Feb 20, 2019

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.

@odiferousmint

This comment has been minimized.

Copy link
Author

commented Feb 20, 2019

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?

@aofei

This comment has been minimized.

Copy link

commented Feb 20, 2019

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?

@odiferousmint

This comment has been minimized.

Copy link
Author

commented Feb 20, 2019

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?

@bcmills bcmills changed the title Is `GOPATH` going to be deprecated? cmd/go: Is `GOPATH` going to be deprecated? Feb 20, 2019

@bcmills

This comment has been minimized.

Copy link
Member

commented Feb 20, 2019

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.)

@bcmills

This comment has been minimized.

Copy link
Member

commented Feb 20, 2019

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.

@aofei

This comment has been minimized.

Copy link

commented Feb 21, 2019

Thanks, @bcmills. :-)

@odiferousmint

This comment has been minimized.

Copy link
Author

commented Feb 21, 2019

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.

@renathoaz

This comment has been minimized.

Copy link

commented Feb 21, 2019

@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?
@odiferousmint

This comment has been minimized.

Copy link
Author

commented Feb 21, 2019

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.

@odiferousmint

This comment has been minimized.

Copy link
Author

commented Feb 21, 2019

@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.

@ALTree

This comment has been minimized.

Copy link
Member

commented Feb 23, 2019

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.

@ALTree ALTree closed this Feb 23, 2019

@golang golang locked as resolved and limited conversation to collaborators Feb 23, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.