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

proposal: cmd/go: add go work use -r -maxdepth #52381

Closed
sding3 opened this issue Apr 16, 2022 · 9 comments
Closed

proposal: cmd/go: add go work use -r -maxdepth #52381

sding3 opened this issue Apr 16, 2022 · 9 comments

Comments

@sding3
Copy link
Contributor

sding3 commented Apr 16, 2022

I propose that we add a new optional -maxdepth <uint> flag to go work use -r moddirs. It limits the level of directories to descend into for each moddirs, like how the -maxdepth in the Unix find command works.

@gopherbot gopherbot added this to the Proposal milestone Apr 16, 2022
@seankhliao
Copy link
Member

what are the practical/real world cases is which this is useful?

@sding3
Copy link
Contributor Author

sding3 commented Apr 16, 2022

most go modules are defined at the root directory of repos, and most people have go projects cloned onto their local filesystem either in one directory (flat layout) or in a hierarchy of sub-directories with a known/limited depth. So a -maxdepth flag can be used to limit the search scope in these cases and prevent bogus or unwanted go.mod files from becoming accidentally included in the work space (e.g. issue #51959) at which point users would then have to prune those out, which is cumbersome.

@seankhliao
Copy link
Member

Depth seems like a poor proxy for the actual issues, a multi module repository can easily have modules at different depths, while a checked out dependency in the same workspace (eg, x/tools from the other issue) may have "unwanted" go.mods at the same depths.
I don't see this as a generally useful mechanism for excluding unwanted module declarations.

@sding3
Copy link
Contributor Author

sding3 commented Apr 16, 2022

-maxdepth is only useful for cases where the desirable depth of directory for where to find go modules to be included in the work space is known. I suspect this is the common case.

Even for cases where a directory level contains both desirable go modules and undesirable ones, limiting the search scope with a max depth would result in fewer (or equal) undesirable ones that need to be pruned out than that of allowing the search scope to be unbound.

@ianlancetaylor ianlancetaylor changed the title proposal: add -maxdepth to go work use -r proposal: cmd/go: add -maxdepth to go work use -r Apr 17, 2022
@ianlancetaylor ianlancetaylor added the GoCommand cmd/go label Apr 17, 2022
@ianlancetaylor ianlancetaylor added this to Incoming in Proposals (old) Apr 17, 2022
@ianlancetaylor
Copy link
Contributor

CC @bcmills @matloob

@rsc rsc changed the title proposal: cmd/go: add -maxdepth to go work use -r proposal: cmd/go: add go work use -r -maxdepth Dec 4, 2023
@rsc
Copy link
Contributor

rsc commented Dec 4, 2023

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

@rsc
Copy link
Contributor

rsc commented Dec 6, 2023

Because -r is not the default, another option is to use other file walking tools to prepare a list of directories passed to go work use. It seems like -r does not need all the bells and whistles.

@sding3
Copy link
Contributor Author

sding3 commented Dec 9, 2023

Because -r is not the default, another option is to use other file walking tools to prepare a list of directories passed to go work use. It seems like -r does not need all the bells and whistles.

Yeah, I'm okay with that.

@sding3 sding3 closed this as completed Dec 9, 2023
@rsc
Copy link
Contributor

rsc commented Dec 14, 2023

This proposal has been declined as retracted.
— rsc for the proposal review group

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Declined
Development

No branches or pull requests

5 participants