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: add ability to allow mod tidy to ignore certain subdirectories #48859

Closed
chewxy opened this issue Oct 8, 2021 · 4 comments
Closed

cmd/go: add ability to allow mod tidy to ignore certain subdirectories #48859

chewxy opened this issue Oct 8, 2021 · 4 comments
Labels
FrozenDueToAge GoCommand cmd/go NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Milestone

Comments

@chewxy
Copy link

chewxy commented Oct 8, 2021

What version of Go are you using (go version)?

$ go version
go version go 1.17.1 linux/amd64

Does this issue reproduce with the latest release?

Yes? Will try later

What operating system and processor architecture are you using (go env)?

go env Output
$ go env

What did you do?

Context
I'm using git. I'm working on a long running new-version branch. I receive a request to patch something on main branch. So I quickly create a new branch from main. Think of it as something like this:

    │
    │\
    │ \
    │  \
    │   │
    │   │
main│   │
    │   │
    │   │newver
    │   │
    │   │
    │   │
    │   │
    │   │
    │   │
    ▼   ▼
     \
      \
       \
        │
        │patch
        │
        │
        ▼

Now in the newver branch there are a number of new subdirectories/subpackages etc. Because it's quite experimental, not all of the subdirectories will be staged and committed into the branch. Thus when I switch to the new branch, there are some subdirectories that are not removed (let's use for example a subpackage called machine). Some are removed because they're already staged and committed to newver (and let's use for example, a package called statistics) .

What I did
So, now I'm in the patch branch, with some new subdirectories. I add a 2 line patch. Then I run go mod tidy.

go mod tidy recursively goes into each subdirectory and does its module thing. Fantastic. The issue is the code in machine refers to the subpackage statistics. Ah, now we run into a problem - it's going to be 404 not found (unrecognized import path).

What I did to overcome the issue

There were two options I had:

  1. stash the changes in patch branch, go back to newver, make a new branch off newver, call it newverexp and add all the experimental stuff that is not ready for newver, then go back to the patch branch, unstash the changes, run go mod tidy and push changes. Outcome: I now have more branches to manage!
  2. backup those subdirectories and delete them, run go mod tidy and then restore them from backup.

Either way, both options took more time than expected. Now, you might say "this is just your poor git hygiene". And I'd be inclined to agree with you.

What would be nicer

It would make things a lot more expedient if I could just tell go mod tidy to not recursively go into certain directories that has .go files in them because:

  1. they may actually be data files with the same extension
  2. they may be temporary
@mvdan
Copy link
Member

mvdan commented Oct 8, 2021

Going the route of #30058, have you thought of dropping a temporary go.mod file in that subdirectory? Then any commands like go mod tidy or go build ./... would entirely skip it. It doesn't matter what the go.mod file contains, it could be entirely empty - the point is that with such a file being present, then that directory sub-tree is entirely ignored for the parent module, as it's assumed to be a nested module.

@bcmills
Copy link
Contributor

bcmills commented Oct 8, 2021

I think there are already enough options for this sort of use case.

  • Personally, I tend to use git stash in this sort of situation.
  • A temporary go.mod file to prune out the new code, as Daniel suggests, would also work.
  • Or you could temporarily rename the machine directory to _machine or similar. (The go command ignores directories that begin with _ or . or are named testdata.)
  • Or, use go mod tidy -e to suppress the error for the missing statistics package. (That may still add dependencies for other packages imported by machine, though.)
  • Or, as you noted, commit the changes on a branch somewhere, and remember where you left them. (I often have work-in-progress commits in my working branch on top of the work that I've already mailed out for review — the Go project's git codereview tool even recognizes sentences like DO NOT MAIL and DO NOT MERGE in commit messages for exactly that sort of situation.)

Honestly, I think that list of options is already too long — it's hard to know which to use when! I don't want to add to it further. 😅

@bcmills bcmills added this to the Unplanned milestone Oct 8, 2021
@bcmills bcmills added GoCommand cmd/go NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. labels Oct 8, 2021
@seankhliao seankhliao changed the title go mod tidy: add ability to ignore certain subdirectories cmd/go: add ability to allow mod tidy to ignore certain subdirectories Oct 8, 2021
@mpx
Copy link
Contributor

mpx commented Oct 11, 2021

It might be useful to document these options somewhere easily found when using mod tidy. I suspect many people will find options beyond git stash non-obvious (eg, skipping _ is not that well known, same with using go.mod to suppress dependencies).

FWIW, I regularly do the git stash; go mod tidy; git stash pop dance, along with moving/renaming files. I'd be interested to improve this workflow, but I'm not sure what that would look like. For Git, it would be convenient if go mod tidy had an option to only consider files in the index -- but this level of integration probably isn't appropriate.

@gopherbot
Copy link
Contributor

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)

@golang golang locked and limited conversation to collaborators Nov 8, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge GoCommand cmd/go NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Development

No branches or pull requests

5 participants