cmd/go: conversion does not preserve replacements from dep, glide, govendor, etc #25556
Comments
|
Checked two imports:
|
|
You can see from our glide.yaml file that these are both forked packages: So, commit has to be searched in the fork, I believe. |
andybons
changed the title
|
You can add a replace into |
|
@oiooj , the issue is that |
|
It seems that in order for this repository to be compatible with This closely relates to one of the examples in Part 9 of @rsc's blog series:
¹ See the “Replacing Modules” section of https://research.swtch.com/vgo-mvs. |
|
That said, it does seem like It seems likely that you'd still need to rewrite the imports in order for |
bcmills
changed the title
rsc
changed the title
|
Note that #25692 was an instance of this in govendor. |
|
Change https://golang.org/cl/120075 mentions this issue: |
…lude statement Now modconv is only work with the basic cases, we need support "replace" and "exclude" from legacy config. In followup CLs, It will preserve replacements from glide and vendor.json. Updates golang/go#25556 Updates golang/go#24087 Change-Id: Ie5ca8df7f685177afea9cc7affcc6240b38223b5 Reviewed-on: https://go-review.googlesource.com/120075 Reviewed-by: Russ Cox <[email protected]>
rsc
changed the title
|
@rsc , I tried with the
You can see the generated I see that it is missing all the forks. I also see that it is missing transitive dependencies. For example, in the to fix some bugs in upstream Kubernetes repos. I don't see |
bcmills
changed the title
bcmills
changed the title
rsc
changed the title
|
@tamalsaha It reads glide.lock, not glide.yaml. It doesn't have the lines for apimachinery because it doesn't convert replacements (the hashes listed in glide.lock don't exist in the main repos). If we started converting replacements (and first understood exactly what that meant, which we don't quite), then more might work. But I'm glad you are getting a go.mod now. We won't be doing replacement conversions for Go 1.11. |
|
what happens when we see something like |
|
I am able to generate |
I have a fork of |
I would very much like to have an answer to that very question as well. Currently trying to move a fairly large codebase to being a module on Go 1.11.x and the inability to override third-party dependency requirements to use a specific patch version of another third-party project is problematic (*). (*) Problematic as in requiring multi-month engineering work with significant inherent risk to update our fork to a newer version of the upstream which contains breaking changes between minors (golang/protobuf#607 sigh). |
|
I see that support for dep |
|
If anyone is looking at this for other tools, Go 1.13 picked up the ability to convert the Note: there probably first should be agreement from someone like @jayconrod or @bcmills that a given tool is worth pursuing, though. |
|
@jayconrod @bcmills Please let me know if that's something you'd like to see implemented |
|
@rafaelvanoni, that seems fine once the 1.14 tree opens, provided that the amount of code isn't huge. |
|
@rafaelvanoni just to briefly expand slightly more on Bryan's point, it's 100% fine to send a CL now, or whenever you might have the time. (Bryan's point is that it wouldn't get merged or probably reviewed until the 1.14 tree opens). |
|
Cool, just wanted to avoid duplicating work. |
bcmills
added
the
NeedsFix
|
Any further |
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env)?What did you do?
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
I checked out master branch of https://github.com/pharmer/pharmer repo and ran
vgo build. This repo uses glide currently.What did you expect to see?
go.modfile.What did you see instead?
The text was updated successfully, but these errors were encountered: