[na85]

Ugh, reading this reminded me why I felt good moving away from Go after the honeymoon period was over.

Actually writing the code was fun at first, but everything else around the actual act of composing code was thoroughly awful UX.

[kitd]

It looks complicated because OP is describing the situations both before and after the introduction of go mod.

Just use go get to get initially, and go mod to organize thereafter. It is very simple and occupies <1% of my cognitive effort writing go code.

[littleroot]

I'm the opposite: I'm writing Go for a living and I hate everything about the language itself, but I found the de-facto toolchain ok-ish and probably the least obtrusive thing about the whole thing.

Imho, many languages would massively benefit with the kind of tooling Go has out of the box. I heard Rust's tooling has some great stuff too and it's in my immediate plan to learn some Rust.

[nlnn]

I've had a similar experience, though my pain points were mostly around using privately hosted modules internally.

I forget the solution, but involved messing about with the `GOPRIVATE` env variable, adding some `.insteadOf` entries to git config, plus similar fun trying to get the same happening in a CI environment.

[mkdirp]

I'd love to understand what you think the issue is. I feel like go dependencies have been extremely easy since modules were introduced and I've rarely had issues.

[philosopher1234]

Can you elaborate? It seems to me like the minimum set of features I want from package management

[CannisterFlux]

I have a go thing I wrote that I hadn't touched for years but had the misfortune to need to modify it recently, and the way to migrate from $GOPATH/src/ to go.mod is not really clear (to me at least). To build this thing, the only go code I have, I used git submodules to put all the dependencies in ./src, so I had ./src/github.com and a load of 3rd party modules in there, then my code was in ./src/Mything. To build it, I ran "env GOPATH=$PWD go build Mything/MyPackage" and it did the right thing, with the final binary appearing in the current directory.

Now this gives an error "go.mod file not found in current directory", but if I add that file, go build says "unexpected go.mod file found in current directory".

Luckily, for now, I can use GO111MODULE=off to keep pretending everything is fine, but my eyes start to glaze over when I read the migration guide at https://go.dev/blog/migrating-to-go-modules - it's one of those moments where I start to wish I'd used a different language :(

[philosopher1234]

I’m pretty sure the migration is just

1. Go mod init in your code’s root dir 2. Done..? Go get ./…?

[CannisterFlux]

Nah, I wish it were it that easy. There is definitely more yak shaving involved.

"go mod init" returns the error "go: cannot determine module path for source directory".

"go mod init src/mything/mypackage" creates a go.mod file, but then "env GOPATH=$PWD go build mything/mypackage" says "$GOPATH/go.mod exists but should not" (as opposed to when it isn't there, then go complains "go.mod file not found in current directory")

Note that "env GOPATH=$PWD GO111MODULE=off go build mything/mypackage" does build all the source code.

Most likely I've set the whole project and directory structure up wrong, and it only works by brute force.

[arccy]

it should have been `go mod init mything/mypackage` (without the `src/`) in the `GOPATH/src/mything/mypackage` directory, and `GOPATH=$PWD` is almost certainly wrong. The `go` command in module mode assumes independence from GOPATH, so to build something, you have to be "in" the module (under a directory with a `go.mod` file).

[CannisterFlux]

Thanks, I've been checking on project layouts, and I have mine definitely wrong / weird. Which is probably why I've made life difficult for myself.