Remove dependency of GOPATH

[ghost]

ponzu will not work with go (1.13.1 tested) when GOPATH is set to anything other than GOROOT. All commands execute without complaint, but content and add-ons don't show up. I propose that since GOPATH is no longer required, and in fact go projects can now be located anywhere in the filesystem, ponzu should work with relative paths.

To replicate, using a recent version of go:

1. cd into some arbitrary directory and create a go.mod file, create a main.go hello world, and prove that go does not require projects to be in GOPATH.
2. Unset GOPATH and do the same thing, and prove again that this works.
3. Now in this directory, try to use ponzu. If GOPATH is unset, ponzu will create the project in GOROOT, which is probably not what the user wants to happen.
4. Set GOPATH to some directory other than GOROOT and use ponzu; it will force a directory structure with $GOPATH/src/repository.domain/project. Again, probably not what a modern go user would expect.
5. [dependency] Vendor all dependencies #4 will succeed; go ahead and generate a content type and use ponzu build to build the project. The content files will be created and the build will succeed.
6. Use ponzu run to start the project, and open a browser to the admin page. The page will show, but no content will be displayed.
7. Try to add an add-on; the add-on will be added to the correct subdirectory in the current directory. Rebuild and re-run, and go to the admin page again. The add-on will not be shown.

Following the core go team's lead, it'd be great if ponzu also removed hard-coded dependencies on GOPATH and GOROOT, and used relative paths. This is beyond my knowledge of Go internals, but it will probably require ponzu to become go.mod aware.

[olliephillips]

Yes, bit of an elephant in the room this one.
Good that we have it documented here now - thank you!

My initial thoughts and questions, for discussion.

1. The Ponzu repo itself, should be compatible with go mod like any other.

2. Ponzu CLI binary is impacted. Is it a breaking change or can we maintain backwards compatibility with older versions of go?
   A quick inspection of the code suggests that the gopath resolution - to default or custom - is abstracted into the cmd/ponzu/paths.go file. More logic could be added to detect go version, and then operate with relative paths, so backwards compatibility could be possible. And this may be the extent of it.
   Alternatively, the repo could be major versioned and support for deprecated gopath dropped?

3. Does ponzu cmd need to do anything additional to make a ponzu project go mod compatible? You mention "become go.mod aware", but since the tooling underneath is all using the go command it may be enough for ponzu to wrap a go mod init in a new ponzu project ( again, maybe if the version of go demands it). The build operations based on the gocmd should produce the required go.sum etc.

4. Vendoring. I "think" for the purpose of moving a ponzu project to a server, the project dependencies are vendored. I'm not currently aware if this uses an established vendoring approach, but certainly go mod has a vendoring option. Should the current approach to vendoring also be changed?

I'm sure there is more, but these were my initial thoughts.

[nilslice]

I've intentionally held off on this one as the Go team has gone through a number of iterations on modules and how GOPATH will play out. Now that it's baked, I would definitely like to get this one solved.

There are some changes that can be made to simplify the path resolution in terms of "where is the project" and "where do I need to move some files for compilation".. these decisions were made really early, to hack-in some benefits to the developer experience, but with modules being first-class, we can now assume a lot more about the environment than could be done before.

I will have some time in a couple of weeks to dive in deeply on this - as I know it is super impactful to ponzu users and the longevity of the project. Thanks for opening up this issue for tracking, and for the thoughts and feedback. I'll update this thread as I make any progress.

[olliephillips]

If I can help @nilslice please shout. You are ahead of many I suspect :)

I think many think of go mod as additional, rather than something that now ultimately deprecates gopath. Although, Ponzu has some characteristics that make it more sensitive for sure.

[jiayiwang7]

ponzu will not work with go (1.13.1 tested) when GOPATH is set to anything other than GOROOT. All commands execute without complaint, but content and add-ons don't show up. I propose that since GOPATH is no longer required, and in fact go projects can now be located anywhere in the filesystem, ponzu should work with relative paths.

To replicate, using a recent version of go:

1. cd into some arbitrary directory and create a go.mod file, create a main.go hello world, and prove that go does not require projects to be in GOPATH.
2. Unset GOPATH and do the same thing, and prove again that this works.
3. Now in this directory, try to use ponzu. If GOPATH is unset, ponzu will create the project in GOROOT, which is probably not what the user wants to happen.
4. Set GOPATH to some directory other than GOROOT and use ponzu; it will force a directory structure with $GOPATH/src/repository.domain/project. Again, probably not what a modern go user would expect.
5. [dependency] Vendor all dependencies #4 will succeed; go ahead and generate a content type and use ponzu build to build the project. The content files will be created and the build will succeed.
6. Use ponzu run to start the project, and open a browser to the admin page. The page will show, but no content will be displayed.
7. Try to add an add-on; the add-on will be added to the correct subdirectory in the current directory. Rebuild and re-run, and go to the admin page again. The add-on will not be shown.

Following the core go team's lead, it'd be great if ponzu also removed hard-coded dependencies on GOPATH and GOROOT, and used relative paths. This is beyond my knowledge of Go internals, but it will probably require ponzu to become go.mod aware.

Ran into the exact same issue. go mod is essential for many go development now.
Would be really nice to see ponzu's update accordingly.

[andyinabox]

👍 this is kind of a dealbreaker for me