Hacker News Reader

Comment by carbocation | Hacker News Reader

I'm trying to understand the right place to use workspaces.

For example, one of my repos contains a bunch of command line tools (under /cmd/toolA, /cmd/toolB subfolders) that make use of shared libraries. Right now, that's one module. But I suppose these could also be separate modules that are joined by a shared workspace.

They go into this a little bit under the "Work with multiple interdependent modules in the same repository" section. But what they tout as the benefit in that section isn't really a problem in my current workflow. What would be useful is to let my tools depend on different versions of libraries; I think this might be enabled by workspaces? (whereas right now they share a go.mod)

View on HN

I think of workspaces as "a folder containing all of my projects".

Say I'm working on project A, project B, and misc-utils. Projects A and B include misc-utils. I put project A, project B, and misc-utils in the same folder along with go.work. Then, if I need to add something to misc-utils for project A, I don't have to re-publish misc-utils for it to affect project A, it does so automatically.

Now you can already do this by editing the go.mod of project A so that it depends on the local version of misc-utils, but then you have to make sure to revert to the upstream version whenever you publish project A.

In your case if the dependencies are already in your repo, then you're fine. A workspace is good if you have multiple repos which depend on one another, and you're working on all of them at the same time.

Sounds like virtualenvs in python. I'm excited to play with it.

I always thought venv solved a problem of multiple dependency versions on the same system, without conflicting. Go modules already handled that pretty well. This is specifically for cases where you have modules you are using in some code that you also want to actively develop on, and you would rather not constantly push code to a hosted VCS just to be able to `go get server.com/my/dependency@some/branch`, which is the primary use case modules solve: code versions from remotes in a consistent and verifiable way.

Workspaces just simplifies that workflow so that you can make changes locally in `a` which is used by `b` without ever pushing `a`, and without needing them to be within the same module.

pip install takes a local path not just a url.

So long as `a` and `b` are both in the virtualenv (on the path somewhere) it doesn't matter where you got a from and you don't need to push your changes globally. If you start tweaking `a` it won't effect anybody outside the virtualenv either.

Particularly useful when you use -e — the virtualenv will only reference your package, not copy the source. Very useful for development and I learned it way too recently.

> I think of workspaces as "a folder containing all of my projects".

This really reminds me of the approach that the Eclipse IDE takes.

Some loved it, some hated it - much like how i might want to organize my Go and other projects in rather arbitrary ways, e.g. in a bunch of subfolders where Git checkouts are done, like:

  ~/projects_work/project_{bar,baz}
  ~/projects_personal/2022/project_{baz_but_altered,other}
  ~/Downloads/temp_stuff/*

Think of a monorepo (multiple go.mod files).

As opposed to what you’ve referenced: a single repository that contains a single go.mod.

Yes what you're describing sounds like what I (think) I want to convert my repo to be more like. I'll experiment.

I'm looking forward to the improved editor experience as gopls is now workspace-aware.

There's a couple of repos at work which contain multiple Go modules (each in their own subdirectory, with their own go.mod files). It's a bit of a pain to get LSP working correctly for each individual module if I open the root directory of the repo in my editor.

> There's a couple of repos at work which contain multiple Go modules (each in their own subdirectory, with their own go.mod files).

There's almost no reason to do this. 1 repo = 1 module. Even for monorepos.

Can you elaborate? What if you have multiple commands (main.go) with differing dependencies?

They can (and usually should) exist in a single module. Each compiled artifact will link in only the dependencies it requires, not all of the dependencies of the parent module.

Reply on news.ycombinator.com