Any chance of not deprecating GOPATH ?

[Randall O'Reilly]

Apologies for being really slow on the uptake here, but I’m just now realizing that the master plan is to actually get rid of the GOPATH mode! Is there any chance of possibly retaining it? Is it too much work to maintain both modules and GOPATH modes? I have absolutely no qualms with the modules and recognize that it is essential and a major improvement (and a huge amount of work).

But I really like GOPATH! See: https://divan.dev/posts/gopath/ for some similar sentiments.

In short, GOPATH is great for simple, transparent, easy access to the source code, and in general it tends to work fine most of the time. I have always thought of the modules as a kind of extra-hassle mode for “business types” that really need reproducible builds all the time, whereas “casual / lazy hackers” can just live in GOPATH and do just fine, especially when mostly dealing with their own code space (and especially across multiple packages).

So far, I’ve just been treating modules as something to update whenever I make an official tagged release, but that strategy seems to not work very well in practice, and, being lazy, have just been advising my users to turn GO111MODULE=off. I’ve also generally been ignoring discussions of modules and apologize if this is a retread — just point me to the relevant discussion (didn’t find it in a quick search, except maybe in golang issues which are too long!)

Has someone written a short guide to replicate the “live source” mode of GOPATH within modules, so you can easily be updating code across multiple packages (and repositories) without having to do a lot of extra work to get one package to use the current version of the other etc? That at least would be super handy, if it is possible.

- Randy

[Tamás Gulácsi]

See the "replace" directive of go.mod.
replace my/pkg => ../../my/other/pkg
Will use that other pkg instead of my/pkg.

[Randall O'Reilly]

Thanks for the tip — that led me to these other relevant discussions:

* https://groups.google.com/forum/#!searchin/golang-nuts/gohack$20replace$20modules
* https://www.reddit.com/r/golang/comments/cvapcu/go_mod_how_to_get_it_to_find_packagesmodules_in/
* And now I understand the point of this tool: https://github.com/rogpeppe/gohack
* And here’s a very helpful tutorial: https://dev.to/maelvls/why-is-go111module-everywhere-and-everything-about-go-modules-24k

(It is worth noting that the official blogs don’t really address this issue — I just looked for “replace” in these blogs and it isn’t discussed: https://blog.golang.org/v2-go-modules)

The issue I’m having is well summarized from the reddit thread:

> Eg. Say I’m developing a library and a program at once. If I make changes to the library, I also need to upload it to its git repo so it downloads it. Alternatively, I can use the redirect. But then when I commit it to git, I then need to remove the redirect line, otherwise the user who downloads the program source needs to manually download the other library.
> It just makes development between two separate git repos really really fucking hard. Before, I could just leave them In gopath and then I could edit them both and work on them together. Then someone grabbing just the app would just grab the dependency and it was done.

Given the prevalence and advantages of splitting large projects into different libraries & packages, the extra difficulties in dealing with this situation seem like a real impediment (and gohack doesn’t really solve the problem it seems — more for minor hacking but not for full-scale parallel development across packages / repos).

The current support for both GOPATH *and* modules seems like an ideal situation to me: there are two effective “branches” of the code (even without the extra hassle of git branches): the current GitHub code, and the tagged released versions with go.mod’s as needed for those releases. Anyone who needs a stable build gets the tagged release and gets their reliable build using modules. And the developers and bleeding edge folks can just live out of GOPATH as before. No need to remember to remove replace directives, etc — everyone’s happy (once you get past setting GO111MODULE appropriately)! So maybe it could just be left this way :)

- Randy

> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/9288880b-244f-4c5a-a188-c1a723ec8d76%40googlegroups.com.

[Wojciech S. Czarnecki]

Dnia 2020-02-01, o godz. 18:16:11
Randall O'Reilly <rcore...@gmail.com> napisał(a):

> But I really like GOPATH! See: https://divan.dev/posts/gopath/ for some similar sentiments.

I concur!

See also https://github.com/golang/go/issues/26640, recently reopened,

2020-02-01 22:50:27 időpontban Tamás Gulácsi <tgula...@gmail.com> a következőt írta:

> See the "replace" directive of go.mod.
> replace my/pkg => ../../my/other/pkg
> Will use that other pkg instead of my/pkg.

This still is mostly manual labor, a source of discrepancies and a mess comparing
to the GOPATH established flows — it feels especially at early development stage.

The flow I would like to have on the belt:

1. set GOPATH, then experiment freely having at hand **all** needed 3rd party
and __all_of_my_own__ production sourced locally. The go.mod exists but is empty.

2. In rare cases experiments need not the tip of some package, use go.mod.local
not to 'replace' but to pin version/commit only.

3. go mod tidy && go mod release # make the go.mod as of current package shape
commit && tag && push # publish, fix version, possibly make to the modules cache

--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE

[Amnon Baron Cohen]

Kill GOPATH!

It was a terrible idea. Thankfully no longer needed.
But it causes no end of confusion.

[Manlio Perillo]

Currently I'm using a simple hack, taking advantage of git.

1. Set the GOPRIVATE goenv variable to the prefix of your projects.

    In my case it is github.com/perillo

2. Update ~/.gitconfig with an URL rewrite, to map https://<modulepath> to the local GOPATH using SSH.

    [url "ssh://manlio@localhost:/home/manlio/src/go/src/github.com/perillo/"]

     insteadOf = https://github.com/perillo/

One issue it that the go tool will never again get your modules from the network.

I have set GO111MODULE=on.

Manlio

[suyatn...@gmail.com]

what part of GOPATH that confuse you ?