cmd/go: put workspace commands under `go work`

[matloob]

This proposes an amendment to the Workspaces Proposal #45713, that was originally suggested by @jayconrod (with a small tweak from me).

Instead of naming the commands to create and edit go.work files go mod initwork and go mod editwork, name them go work init and go work edit. This makes future subcommands (such as the proposed add and sync subcommands) have more clear names.

@jayconrod's comment proposed the names go workspace init and go workspace edit.

cc @ianthehat @bcmills

[complyue]

And I anticipate that once go work family of cmds released & mature to stable, go mod family of cmds together with go.mod files, should only work with (cached) committed revisions of modules; then uncommitted revisions of each module can only work as manifested by go.work file, together with go work xxx cmds.

Maybe this means an app that never be dependency of other modules will only need a go.work, no go.mod anymore.

[bcmills]

@complyue, the go.mod file provides the module path (which is an import-path prefix) for the packages within the module, and provides the required versions of dependencies of that module.

The go.work file provides neither, nor should it: the roots that the go.work file adds to the module graph are unversioned. go.work tells you which modules are in the workspace; go.mod tells you which packages are in (and needed by) a module.

[complyue]

@bcmills Sorry I haven't went thoroughly through the specs wip, I think I'm still having Haskell's project manifestation grammar in mind and suppose go.work is going on a par.

If go.work is not designed to be able to pull in some experimental/wip branch (or by tag, by commit hash etc.) of a go.mod repository into scope, I would propose for it.

When more than a few days or more than a couple of personnels are required to work out a feature set with multiple go.mod involved, coordinated experimental branches are desirable in case.

It's quite reasonable in software engineering practice, for some members to make "wip releases" of some go.mods (out of all wip modules) to the rest of the collaborators, and it's desirable in certain cases, for someone depending on them but working on other modules, to track such intermediate dependencies by branch (i.e. without local check out & manual sync 1 by 1). It's better for some tool to do the whole job with one shot, e.g. a single go work pull cmd to update all such cached branches to date. That will come really convenient.

[complyue]

Pls forgive my laziness to refresh the knowledge myself, by now with go.mod mode exclusive on, do .go src have to be within some go.mod subdir to be buildable?

I assumed such "out-of-mod" packages are still buildable, and even relative imports can work there. Is that the case or I'm wrong?

I mean there are the part of end app source, mapping 1:1 to the end problems, they must adjust to business changes, put them reused will increase the cost for change implementation per business process. So they better never get reused (imported) by other modules, thus also better stay out of any go.mod, to make the intention more obvious, and mistakes harder to make.

[jayconrod]

@complyue We aren't proposing any change to module mode here. This proposal is just about renaming a command from #45713.

#45713 adds a new workspace mode which makes it more convenient to work on a change that affects multiple modules. Module mode still works as it did before, and it will still be necessary to commit and tag releases for multiple modules separately. We're not proposing a solution to that yet.

If go.work is not designed to be able to pull in some experimental/wip branch (or by tag, by commit hash etc.) of a go.mod repository into scope, I would propose for it.

That hasn't been proposed. Feel free to start a new proposal, but please keep in mind how this would be implemented and what the experience would be like. If there were a command to checkout a module at a given commit into a directory, then add that to go.work in one step, that might work well; but making the go command check whether a branch has changed on every build probably would be too slow.

Pls forgive my laziness to refresh the knowledge myself, by now with go.mod mode exclusive on, do .go src have to be within some go.mod subdir to be buildable?

I assumed such "out-of-mod" packages are still buildable, and even relative imports can work there. Is that the case or I'm wrong?

For almost all cases, packages must be inside a module to be buildable. It is possible to build small programs as .go files listed on the command line, but they cannot import anything outside the standard library. Relative imports also are not allowed in module mode.

[rsc]

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

[rsc]

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group