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

Jump to bottom

cmd/go: allow 'go mod vendor' to omit replaced modules #33789

Open
mkeeler opened this issue Aug 22, 2019 · 6 comments
Open

cmd/go: allow 'go mod vendor' to omit replaced modules #33789

mkeeler opened this issue Aug 22, 2019 · 6 comments
Labels
FeatureRequest modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Backlog

Comments

@mkeeler
Copy link

mkeeler commented Aug 22, 2019

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

$ go version
go version go1.12.9 darwin/amd64

Does this issue reproduce with the latest release?

Yes

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

go env Output
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/mkeeler/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/mkeeler/.go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/mkeeler/Code/repos/consul/master/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/dc/5dk846911dbdkmjk4bj47hhm0000gn/T/go-build297831786=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

  1. git clone https://github.com/hashicorp/consul
  2. go mod vendor

What did you expect to see?

I didn't expect vendor/modules.txt to contain the nested modules within it nor having those nested modules be vendored into the top level vendor folder.

What did you see instead?

Nested submodules are vendored.

We currently get around this by postprocessing the modules.txt and the vendor directory. I realize that nested modules might not be a great idea (it has caused me a number of headaches) however for code living in the same repo the current go mod vendor behavior of vendoring our own code doesn't make much sense to me. Is this intended behavior or just something that isn't protected against.
@bcmills
Copy link
Contributor

bcmills commented Aug 22, 2019

Is this intended behavior or just something that isn't protected against.

At the moment, this is working as designed: go mod vendor doesn't know (or particularly care) about the overall repo structure — it just knows where the main module is and vendors in the dependencies of the main module wherever they are found.

Omitting same-repo dependencies is one of the use-cases I had in mind for partial vendoring (#30240).

@bcmills bcmills added modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Aug 22, 2019
@bcmills bcmills changed the title cmd/go: go mod vendor vendors nested modules in the same repo cmd/go: allow 'go mod vendor' to omit nested modules in the same repo Aug 22, 2019
@bcmills bcmills added this to the Unplanned milestone Aug 22, 2019
@bcmills bcmills mentioned this issue Oct 3, 2019
Closed
@bcmills bcmills changed the title cmd/go: allow 'go mod vendor' to omit nested modules in the same repo cmd/go: allow 'go mod vendor' to omit replaced modules Oct 10, 2019
@bcmills bcmills modified the milestones: Unplanned, Backlog Oct 10, 2019
@sgreene570 sgreene570 mentioned this issue Nov 6, 2019
Closed
@shoenig shoenig mentioned this issue Jun 4, 2020
Merged
@shoenig shoenig mentioned this issue Jun 16, 2020
Merged
@carter2000
Copy link

@bcmills Any plans for partial vendoring ?

@bcmills
Copy link
Contributor

bcmills commented Aug 28, 2020

This issue is milestoned to Backlog. So not at the moment, no.

@shoenig shoenig mentioned this issue Oct 19, 2020
Merged
@shoenig
Copy link
Contributor

shoenig commented Oct 19, 2020

@bcmills is this something ya'll plan to work on? Is it something we can contribute a PR for? This is a sharp edge that burdens us daily.

@bcmills
Copy link
Contributor

bcmills commented Oct 20, 2020

@shoenig, we don't have any specific plans to work on this. If this feature is important to you, some more detail on your use-case (especially the alternatives you considered and the problems with those alternatives) would be helpful.

At the moment, the big question is whether the added convenience is worth the added complexity (of both the implementation and the documentation).

@Joerger Joerger mentioned this issue Feb 4, 2021
Merged
@ShoshinNikita ShoshinNikita mentioned this issue Nov 15, 2021
Open
@snluu
Copy link

snluu commented Sep 3, 2022

@bcmills Thanks for your responses.

The main issue I'm running into with my use-case is where I have local dependencies. Currently, the way that I'm import local dependency is via using replace mydomain.com/mypackage => ../mypackage.

However, this does not work with vendoring, because vendoring would copy ../mypackage to ./vendor/mydomain.com/mypackage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
FeatureRequest modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
5 participants
@shoenig @snluu @carter2000 @mkeeler @bcmills