6 ms·

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 s

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)

disposedtrolley 5y ago
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.
- preseinger 5y ago
  > 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.
  - gkfasdfasdf 5y ago
    Can you elaborate? What if you have multiple commands (main.go) with differing dependencies?
    - preseinger 4y ago
      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.
armchairhacker 5y ago
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.
- recuter 5y ago
  Sounds like virtualenvs in python. I'm excited to play with it.
  - andrewstuart2 5y ago
    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.
    - recuter 5y ago
      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.
oogali 5y ago
Think of a monorepo (multiple go.mod files). As opposed to what you’ve referenced: a single repository that contains a single go.mod.
- carbocation 5y ago
  Yes what you're describing sounds like what I (think) I want to convert my repo to be more like. I'll experiment.

disposedtrolley 5y ago

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.

preseinger 5y ago
> 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.
- gkfasdfasdf 5y ago
  Can you elaborate? What if you have multiple commands (main.go) with differing dependencies?
  - preseinger 4y ago
    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.

armchairhacker 5y ago

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.

recuter 5y ago
Sounds like virtualenvs in python. I'm excited to play with it.
- andrewstuart2 5y ago
  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.
  - recuter 5y ago
    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.

oogali 5y ago

Think of a monorepo (multiple go.mod files). As opposed to what you’ve referenced: a single repository that contains a single go.mod.

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