cmd/go: preserve basic GOPATH mode indefinitely #60915
Comments
|
Do you expect that tools like gopls will continue to support GOPATH mode? While |
|
I would expect gopls and go/packages to continue to support GOPATH as well as they do today. There should be very little special code they need, and it's already written. |
|
This proposal has been added to the active column of the proposals project |
|
What examples are there of GOPATH packages we want to keep working with the latest toolchains? The steps to convert GOPATH packages to modules are:
Unless I missed something, that's not much effort. This is basically equivalent to forking a package that you know will be deleted soon. In a sense, GOPATH packages would be "deleted." Anyone who truly cares can fork their own copy, and turn it into a module for others to use too. How much simpler would the toolchain be without GOPATH support? |
|
An anecdotal data point: My project at work still depends on GOPATH mode to build. Dependencies are managed with a 2015 era tool that automates populating the GOPATH with the desired versions of dependencies, but provides little help deciding what the versions should be. We would have upgraded to Go modules long ago had it been easy, but due to the size of the project, the accumulated complexity of its dependency tree, and other reasons it hasn't happened yet. Not for a lack of desire, by the way. The project policy for the toolchain version is to stay one major version behind, so it's currently built with Go 1.19 and would upgrade to 1.20 shortly after 1.21 is released. Fortunately we have been able to remove some of the barriers to adopting modules over the last several months and I believe we will be upgraded sometime in the next several months. But there may be other projects similar to ours that are not publicly visible, that still need GOPATH, are still actively worked on, and regularly upgrade the toolchain, but are farther away from using modules. Continuing to support GOPATH mode helps projects like that. |
The main quirks remaining to support GOPATH mode have to do with how we resolve dependencies in Beyond that, as Russ mentions, the Speaking as one of the primary maintainers of |
|
@ChrisHines Thanks for your example. I'm curious, how many man hours, working full-time 8 hour days without distraction, do you think it would take to convert that project to an equivalent module? I realize that it's probably non-trivial to do, but I suspect that a lot of situations like that (not necessarily yours, I'm speaking generally) are more a result of management deciding to spend their money on shiny new features instead of maintaining their code, especially since, until now, others have been willing to pay the price to keep them afloat in their current condition. I'm asking so we can have a better sense of the trade-off costs here. |
|
Being able to run old (self-contained) code that predates modules is also worthwhile. That requires having GOPATH build support. Keeping build working is easy and it has real benefits. |
|
@willfaught It would not be a single module. The project has dozens of repositories that will each become a module. About a dozen of those contain packages depended on a few levels deep by the rest of them. We've already invested hundreds of man hours to get things into a state that will make the transition easier (while being careful not to break things or interrupt regular development). At this point the source code is in a good state for a migration. I've already written a tool that can create an equivalent The biggest hurdle for us now is that the tool we've been using doesn't enforce repeatable builds. It allows depending on a branch head. We only use that for internal dependencies, but that implies a certain workflow that developers are used to and that our CI systems have been adapted to. Next steps are working out how to adapt our CI systems and developer workflows to the fact modules don't allow depending on branch heads. Trying things out in a small corner of the project where problems will have minimal impact, then educating people. Prior to the addition of workspaces (go.work) in Go 1.18 the workflow problem looked much more daunting, so I'm glad we have that tool available. The issue has not been management being focused on shiny new features. The project was part way through a migration three years ago, but that was aborted after a key staff member left. I joined the project two years ago and was told almost immediately by management that adopting Go modules was a goal. It's been on the roadmap for a while. But it's a big and old code base with skeletons in many closets that we've been carefully working through. It's really not a matter of 8 hour focus days as much as managing the smooth evolution of an entrenched social-technical system into a better state. |
|
Speaking as Debian packager, I really appreciate that upstream can keep supporting GOPATH for |
|
It may not be clear from my previous messages that in my case we also don't use |
|
Based on the discussion above, this proposal seems like a likely accept. |
|
No change in consensus, so accepted. 🎉 |
rsc
changed the title
|
If I am not mistaken, this will require changes to go/packages, for two reasons:
If we expose the standard library's "std" and "cmd" modules (as per #61174 (comment)), would |
Will |
|
@dominikh Yes, that should work. |
|
Change https://go.dev/cl/518775 mentions this issue: |
|
Linking some related proposals here for posterity's sake: |
|
Change https://go.dev/cl/548875 mentions this issue: |
For #61422. Updates #60915. Change-Id: Ia8ca12c163a02223b26c5e4cd4c1b6093978aba4 Reviewed-on: https://go-review.googlesource.com/c/go/+/548875 Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
For golang#61422. Updates golang#60915. Change-Id: Ia8ca12c163a02223b26c5e4cd4c1b6093978aba4 Reviewed-on: https://go-review.googlesource.com/c/go/+/548875 Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
In Feb 2021 (https://go.dev/blog/go116-module-changes), we wrote:
The time has come to decide what to do about GOPATH mode. There are at least two important problems with maintaining GOPATH mode as it exists today:
The old, GOPATH-mode
go getis being left behind as far as security improvements like the module proxy, checksum databases, and so on. All the focus is on modules.The old, GOPATH-mode source layout does not provide a way to identify the language version used by the source code. There is a bit of divergence here in that a go.mod with no go line assumes Go 1.16, while in GOPATH mode we assume the latest version of Go. This means if someone has downloadable packages they develop in GOPATH mode, they can use language features introduced after Go 1.16, like generics, but when clients download that code in module mode as a "legacy" module, the code is interpreted as Go 1.16 and does not compile. The divergence will become greater over time as other language features or changes are made, such as spec: less error-prone loop variable scoping #60078.
On the other hand, GOPATH mode remains the only way to work on dependency-free legacy packages that existing module code may still depend on (so-called "+incompatible" modules), and it remains the only way to build historical source code that predates modules, especially code that depends on the multiple layers of vendoring that Go 1.5 introduced (and modules removed).
Given these tensions, I propose that we do the following:
We would make these changes for Go 1.22. The GOPATH mode enabler would continue to be GO111MODULE=off rather than introducing a cleaner name like GOMODULE=off, because there's little point to upsetting whatever scripts people with legacy trees have already written.
The text was updated successfully, but these errors were encountered: