Konubinix' opinionated web of thoughts

Golang Go

Fleeting

golang

panic => exit code 2

How to recover from a runtime failure (panic) in Go| Practical Go Lessons

Go runtime prints the stack trace. At the top, you can see the file and line where the panic occurred. It’s easy then to debug! Note also that the exit status code is 2. Which signals an error (0 when all is good)

— https://www.practical-go-lessons.com/post/how-to-recover-from-a-runtime-failure-panic-in-go-cbl28ojpaeds70g0qrs0

workspace

golang go

go.work files should not be checked into version control repos containing modules so that the go.work file in a module does not end up overriding the configuration a user created themselves outside of the module. The go.work documentation should contain clear warnings about this.

— https://go.googlesource.com/proposal/+/master/design/45713-workspace.md

These go.work files should not be checked into the repositories so that they don‘t override the workspaces users explicitly define. Checking in go.work files could also lead to CI/CD systems not testing the actual set of version requirements on a module and that version requirements among the repository’s modules are properly incremented to use changes in the modules

— https://go.googlesource.com/proposal/+/master/design/45713-workspace.md

go.work files should not be checked into version control repos containing modules so that the go.work file in a module does not end up overriding the configuration a user created themselves outside of the module. The go.work documentation should contain clear warnings about this.

— https://go.googlesource.com/proposal/+/master/design/45713-workspace.md

single build list is constructed from the set of workspace modules to give developers consistent results wherever they are in their workspace

— https://go.googlesource.com/proposal/+/master/design/45713-workspace.md

go.work files that checked into repositories would cause confusion for Go users because they change the build configuration without the user explicitly opting in. Because of this they should be strongly discouraged.

— https://go.googlesource.com/proposal/+/master/design/45713-workspace.md

it seems like the common knowledge among Go developers is that the file should never be checked in, because:

GitHub’s default gitignore includes the file since Go: Ignore Go workspace file go.work github/gitignore#3884 Official Go repositories set an example by not checking them in; for example, x/tools does not include one, even though it has two modules connected by a directory replace directive Some third party docs or blog posts echo the recommendation to never check them in, like

https://sebastian-holstein.de/post/2021-11-08-go-1.18-features/

— https://github.com/golang/go/issues/53502

For large monorepos with multiple modules, it likely makes sense to check in go.work, as it makes the setup easier and often has no downsides

— https://github.com/golang/go/issues/53502

We never gave any advice on it, and the community seems to lean on “never check them in”.

— https://github.com/golang/go/issues/53502

We could recommend never checking them in, but I think that’s a bad idea: in some particular scenarios it can make perfect sense to check them in, such as monorepos holding multiple modules.

— https://github.com/golang/go/issues/53502

I would hate to have to teach people in my team how to create a go.work file just so gopls will work as expected for them, so it seems very reasonable to just push it into VCS. That’s why I was very surprised to see the proposal suggested against doing that.

— https://github.com/golang/go/issues/53502

it is possible and perhaps reasonable to check in a go.work file.

— https://github.com/golang/go/issues/53502

For what it’s worth I think it would be fine to fix this issue by updating the docs to say that checking in the file is okay in some cases. Right now we are silent, and there’s widespread “common knowledge” that dictates the file should never be checked in. We should at least clarify that that’s not the official recommendation.

— https://github.com/golang/go/issues/53502

If GOWORK is set to off, the command will be in a single-module context. If it is empty or not provided, the command will search the current working directory, and then successive parent directories, for a file go.work

— https://go.dev/ref/mod#workspaces

Notes pointant ici