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/*