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 init doesn't import nested module, tidy picks older version #33033
Comments
... |
@av86743 I don't think so, because the latest version of |
I do not see logic of what you are saying.
|
I think you're missing the important fact that In fact, there are three submodules (
|
My mistake. Thanks for explaining this to me. Conveniently, github viewer does not indicate submodules visually, and their versions are hiding on the bottom of the tag list. I did see I do not see any references in description of
PS I have looked at git submodules and realized that |
I apologize for the noise - format of tags for nested modules is given in the description of the Modules. Admittedly, absence of any indication whether version belongs to the root module or submodule, does not make inspection of module dependencies any easier. As for your example, you probably do not want to use future exact version, which
|
This seems like a problem with importing from glide.lock, rather than Before you run
When Perhaps we can do something more sophisticated here. We could walk the import graph, figure out what version or commit each package should have been required at, then try to reverse-engineer a go.mod file that produces the same build list. This is close to what |
In general, the module configuration converted from another dependency manager will often require adjustment anyway: for example, some dependency managers have operated at the package (rather than repo) granularity, and migrating those to modules ends up bumping the module version for all of those packages upward to the package with the highest requirement, which can end up pulling in breaking changes. So it's probably more useful to view the converted |
Moving dependencies forward in time is fine - that's something that's going to happen with MVS, and something that can't be avoided; semver compatibility is something we're explicitly buying into when we move to Go modules. Moving dependencies back in time is a problem though. Moving back in time can remove fixes and features even when the publisher has taken care to respect semver requirements. I feel strongly that as far as is possible, For myself, I'm currently migrating over 70 different independent services to using modules. This kind of issue makes for a much more painful experience. There is also the issue that it's not even possible to tell easily whether modules have regressed or not. I've written a little tool to check old and new resolved versions (which is the only reason I discovered this issue and some others), but it's pretty awkward to do. |
There's no such thing as a "semver wildcard" in Go AFAIK. That's not a valid version. |
Exactly. What you suggested does not make sense whatever way I am trying to turn it. No need to bother about it, though. Migrations that you have on hand are more important. |
@rogpeppe: as far as I can tell, there are several conditions that must all be met in order for the version to actually regress:
It certainly is possible to meet those conditions, because you presumably would not have filed this issue otherwise. But I doubt that they co-occur often in practice. |
One might not think so, but the AFAICS this will happen to any module that uses a dependency using glide or dep that imports
I think that's a questionable assertion. The code is importing the latest tagged version of I agree that this whole situation is unfortunate, but I worry that it isn't as uncommon a scenario as you make out. If there was some solution to this that wasn't too hard, I'd still argue that it's worth doing. |
If
IMO, the presence of a
The |
To shed a little more light on the situation here the Consul repo contains 3 modules.
Both the Our general strategy for modules regarding releases is:
The versions of the With regards to the nested module situation, it has been a source of pain for us since implementing it. So much so that we having been considering ways to automate away the nesting. The root problem I see is that we want to be able to PR changes to our public facing API and the corresponding changes to the API client all at once. This means that both bits of code must live in the same repository (at least at the time of the PR). What we are trying to avoid is leaking all of the root modules dependencies to everyone who wants to pull in the API client. One solution I have been thinking through is getting rid of the nested module in the same repo and instead at release time pushing the API client code to a secondary repository where the go.mod would live. This would:
The downside is that many of our users would need to change the import path or now be required to pull in all of the root modules dependencies. I wrote a tool to automate fixing import paths though so the burden on our users would be minimal. |
In this case, the
glide.lock
file depends on a version ofgithub.com/hashicorp/consul
that uses modules and submodules. Beforego mod tidy
, we are depending onv1.5.1
, a commit with date 2019-05-22. Aftergo mod tidy
, the dependency has regressed to the latest availableapi
submodule version,v1.1.0
, a commit with date 2019-05-08.This is a dependency regression which could potentially have broken code relying on new features added between the two commits, something that
go mod tidy
shouldn't be able to do.I suspect that
go mod tidy
needs to use a pseudoversion commit in this case, perhapsgithub.com/hashicorp/consul/api v1.1.1-0.20190522201912-40cec98468b8
.The text was updated successfully, but these errors were encountered: