design/draft-workspace.md: address more comments made on mailing list
Change-Id: I3c5de0e829e5dbbf2283bd881757ee3b0426c807
Reviewed-on: https://go-review.googlesource.com/c/proposal/+/311509
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
diff --git a/design/draft-workspace.md b/design/draft-workspace.md
index 703e2b8..14638ea 100644
--- a/design/draft-workspace.md
+++ b/design/draft-workspace.md
@@ -347,7 +347,7 @@
are properly incremented to use changes in the modules.
As a counterpoint to the above, most go.work files should exist outside of any
-repository: `go.work` files sholud only be used in repositories if they contain
+repository: `go.work` files should only be used in repositories if they contain
multiple tightly-coupled modules. If a repository contains a single module, or
unrelated modules, there's not much utility to adding a `go.work` file because
each user may have a different directory structure on their computer outside of
@@ -404,6 +404,11 @@
alternative versions of the dependencies with replaces, it's easy to switch
between the three configurations.
+Users who want to test using a subset of the workspace modules can also easily
+comment out some of the directory directives in their workspace file instead of
+making separate workspace files with the appropriate subset of workspace
+modules, if that works better for their workflows.
+
#### Workspaces in `gopls`
With this change, users will be able to configure `gopls` to use `go.work` files
@@ -624,10 +629,9 @@
We might want to add a mechanism to ignore all replaces of a module or module
version.
-For example one module in the workspace could have `replace example.com/foo * =>
+For example one module in the workspace could have `replace example.com/foo =>
example.com/foo v0.3.4` because v0.4.0 would be selected otherwise and they
-think it's broken (and they used a wildcard instead of a specific version out of
-confusion or misguided simplicity). Another module in the workspace could have
+think it's broken. Another module in the workspace could have
`require example.com/foo v0.5.0` which fixes the incompatibilities and also adds
some features that are necessary.
@@ -671,3 +675,6 @@
of the set of replaces. It may be helpful to add a command to list the effective
set of root dependencies and replaces and which go.mod file each of them comes
from.
+
+Perhaps there could be a command named `go mod workstatus` that gives an
+overview of the status of the modules in the workspace.
