Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: put workspace commands under go work #48256

Open
matloob opened this issue Sep 8, 2021 · 8 comments
Open

cmd/go: put workspace commands under go work #48256

matloob opened this issue Sep 8, 2021 · 8 comments

Comments

@matloob
Copy link
Contributor

@matloob matloob commented Sep 8, 2021

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

@gopherbot gopherbot added this to the Proposal milestone Sep 8, 2021
@matloob matloob changed the title Proposal: put workspace commands in their own namespace Proposal: cmd/go: put workspace commands in their own namespace Sep 8, 2021
@seankhliao seankhliao changed the title Proposal: cmd/go: put workspace commands in their own namespace proposal: cmd/go: put workspace commands in their own namespace Sep 8, 2021
@complyue
Copy link

@complyue complyue commented Sep 9, 2021

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
Copy link
Member

@bcmills bcmills commented Sep 9, 2021

@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
Copy link

@complyue complyue commented Sep 9, 2021

@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
Copy link

@complyue complyue commented Sep 9, 2021

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
Copy link
Contributor

@jayconrod jayconrod commented Sep 9, 2021

@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.

@ianlancetaylor ianlancetaylor added this to Incoming in Proposals Sep 15, 2021
@rsc
Copy link
Contributor

@rsc rsc commented Oct 13, 2021

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

@rsc rsc moved this from Incoming to Likely Accept in Proposals Oct 13, 2021
@rsc rsc changed the title proposal: cmd/go: put workspace commands in their own namespace proposal: cmd/go: put workspace commands under go work Oct 20, 2021
@rsc
Copy link
Contributor

@rsc rsc commented Oct 20, 2021

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

@rsc rsc moved this from Likely Accept to Accepted in Proposals Oct 20, 2021
@rsc rsc changed the title proposal: cmd/go: put workspace commands under go work cmd/go: put workspace commands under go work Oct 20, 2021
@rsc rsc removed this from the Proposal milestone Oct 20, 2021
@rsc rsc added this to the Backlog milestone Oct 20, 2021
@gopherbot
Copy link

@gopherbot gopherbot commented Oct 21, 2021

Change https://golang.org/cl/357611 mentions this issue: cmd/go: rename go mod initwork and editwork to go work init and edit

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Proposals
Accepted
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants