5 ms·
I always thought venv solved a problem of multiple dependency versions on the same system, without conflicting. Go modules already handled that pretty well. Thi
by 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 agopip 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.
- boardwaalk 5y agoParticularly 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.