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: go mod tidy
ignores go.work
file
#50750
Comments
Tidiness is a property of an individual module, not a workspace: if a module is tidy, then a downstream consumer of the module knows which versions to use for every dependency of every package in that module. If you don't particularly care about downstream consumers having a package that is provided by the workspace, you can use Otherwise, you either need to publish the workspace dependencies before running |
@matloob, for Go 1.19 I wonder if we should augment the |
go mod tidy
ignores go.work
` filego mod tidy
ignores go.work
` file
go mod tidy
ignores go.work
` filego mod tidy
ignores go.work
file
Currently with reproducing repository (https://github.com/bozaro/go-work-play/tree/go-mod-tidy). I can run:
And But for This behaviour looks like inconsistent: I expects that |
What valid use cases are there for |
This is also happening for I agree with @liadmord, the only benefit I see get from the |
I agree with @bozaro @liadmord and @AlmogBaku I have a monorepo private project where I have multiple modules, and on each one I need to insert a lot of |
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
Encountering the same issue with Furthermore, some other
Expected behaviour: The |
My expected functionality is that a If I don't commit my Once I must make an edit to In other words, if I add this line to
Then |
This is a very big issue for me in the case of creating Docker containers :( I cant use Golang is considered the language for microservices and In the current state of the
I expect 4 things from the
So now, the only thing why I'm using |
Signed-off-by: Valery Piashchynski <piashchynski.valery@gmail.com>
I've faced this issue yesterday but my case is a bit different.. My The solution is simply to move the |
Folks who are commenting here (and please bear in mind https://go.dev/wiki/NoPlusOne!) — have you considered |
@bcmills I'm not sure what the intended workflow is, but I think the feedback here is that the DX is really not intuitive. |
I wish there were |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
However that replace directive seems to be ignored by
|
The documentation for workspaces
seems misleading here if not all of the I fully understand and for the most part agree that This could be a case of cleaning up/amending the documentation with further clarifications on what use-cases exactly a |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
Thought I found a workaround, but it's broken in its own unique ways see here Turns out So you can use local module names like
until someone else wants to import those modules (or any modules in your monorepo which depend upon them) Seems like all the building blocks are there to support what's discussed in this issue, but there's logic in various tooling which prevents it. (eg. if Perhaps worth considering either:
|
@bcmills go work sync only works if you actually have a go.work file. Otherwise it errors. I have a scripted install process that involves calling go mod tidy followed by a number of go install calls, all part of a continuous integration process. I was using go.work to be able to test the code in a working branch. However, go mod tidy attempts to grab the code from a release on a main branch. Normally, I want that, but when testing new code in a working branch, I don't. Trying to use go work sync would mean I would have to change the install scripts to do a go work sync if a go.work file was available, and go mod tidy if not. Not too difficult, but a pain. However, running go work sync on a new install gives me errors like this: require github.com/goradd/goradd: version "latest" invalid: must be of the form v1.2.3 So go work sync will not do what is expected, which is to get the latest versions of the packages referred to, except if there is a use directive, in which case it should just use whatever is pointed to. This means I am stuck. I can't call go mod tidy because it will error on a missing package since it will not use the go.work file to find it and so produces an error. And I can't call go work sync because it will not load the latest packages when the go.mod file is asking for it, and so produces an error. Perhaps I am missing an argument that will enable updating of the go.mod file? go help work sync and go work help did not reveal anything helpful in this regard. |
IIUC, Independent of the original intent of As for motivation, many people strongly prefer monorepos for the overwhelming benefits they provide compared to the inconveniences and pitfalls of tightly coupled multi-repo projects. I'm sure Googlers can relate to this :) That said, I can't seem to find a definitive answer on whether monorepos is a first-class use case, and I've read the official docs, tutorials and design doc. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
@bcmills here is an example: https://github.com/BorzdeG/samples.go-and-flutter-grpc If we execute |
@bcmills Maybe the difficulty to resolve this is related to the nature of go.mod, and go.work things. How about just add link to the go.work from go.mod to override the go.work's So, we can ensure that, in case of we cannot find go.work from the link (relative path maybe), then just follow the version and URL, but when we have go.work, then we can follow the path of go.work. Actually, I'm not sure what is the purpose go workspace except seeing monorepo golang code at the same vscode workspace when this cannot be supported. |
Maybe add an |
@BorzdeG I think |
@bcmills Hi, are there any discussion channels for this issue? |
go workspaces appear to be fundamentally broken, see golang/go#50750 for details. This changes the configo repo to be a single module at the root of the repo instead of a workspace containing multiple modules.
What version of Go are you using (
go version
)?What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Minimal reproducing repository: https://github.com/bozaro/go-work-play/tree/go-mod-tidy
Full script:
What did you expect to see?
I expect
go.mod
andgo.sum
updated with current working copy state.What did you see instead?
I see that
go mod tidy
try to get modules forshared
go modules from repository ignoringgo.work
content.The text was updated successfully, but these errors were encountered: