-
Notifications
You must be signed in to change notification settings - Fork 118
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
Errors you may encounter when upgrading the libraries #1640
Comments
@ggriffiths @lpabon Could you help me review this issue? Thx :p |
Hi @KateGo520 Sorry it has taken a while. I will take a look at this this weekend. |
Hi @KateGo520 We have found issues upgrading and have postponed moving to |
(The purpose of this report is to alert
libopenstorage/openstorage
to the possible problems whenlibopenstorage/openstorage
try to upgrade the following dependencies)An error will happen when upgrading libraries prometheus/client_golang and github.com/codegangsta/cli :
For example----
github.com/prometheus/client_golang
-Latest Version: v1.7.1 (Latest commit fe7bd95 on 23 Jun 2020)
-Where did you use it:
https://github.com/alibaba/RedisShake/search?q=github.com%2Fprometheus%2Fclient_golang&unscoped_q=github.com%2Fprometheus%2Fclient_golang
-Detail:
This problem was introduced since prometheus/client_golang v1.2.0(Latest commit ee1078a on 15 Oct 2019) .Now you used version v0.9.4. If you try to upgrade prometheus/client_golang to version v1.2.0 and above, you will get an error--- no package exists at "github.com/cespare/xxhash/v2"
Similar issues can also happen when upgrading libraries github.com/codegangsta/cli (Moved to
github.com/urfave/cli
now),I investigated the libraries (prometheus/client_golang >= v1.2.0) release information and found the root casue of this issue is that----
These dependencies all added Go modules in the recent versions.
They all comply with the specification of "Releasing Modules for v2 or higher" available in the Modules documentation. Quoting the specification:
physical path
. So earlier versions of Go (including those that don't have minimal module awareness) plus all tooling (like dep, glide, govendor, etc) don't haveminimal module awareness
as of now and therefore don't handle import paths correctly See golang/dep#1962, golang/dep#2139.Solution
1. Migrate to Go Modules.
Go Modules is the general trend of ecosystem, if you want a better upgrade package experience, migrating to Go Modules is a good choice.
Migrate to modules will be accompanied by the introduction of virtual paths(It was discussed above).
Then the downstream projects might be negatively affected in their building if they are module-unaware (Go versions older than 1.9.7 and 1.10.3; Or use third-party dependency management tools, such as: Dep, glide, govendor…).
[*] You can see who will be affected here: [3 module-unaware users, i.e., jitin17/Kubernetes_Torpedo, sanjeevm0/KubeGPU-Old, KingOnTheStar/plugin-intermediary]
https://github.com/search?q=libopenstorage%2Fopenstorage+filename%3Avendor.conf+filename%3Avendor.json+filename%3Aglide.toml+filename%3AGodep.toml+filename%3AGodep.json&type=Code
2. Maintaining v2+ libraries that use Go Modules in Vendor directories.
If
libopenstorage/openstorage
want to keep using the dependency manage tools (like dep, glide, govendor, etc), and still want to upgrade the dependencies, can choose this fix strategy.Manually download the dependencies into the vendor directory and do compatibility dispose(materialize the virtual path or delete the virtual part of the path). Avoid fetching the dependencies by virtual import paths. This may add some maintenance overhead compared to using modules.
There are 150 module users downstream, such as Narendarkumar414/KubernetesAutoscaler1, bryanisgreat/autoscaler, cilium/client-examples…)
https://github.com/search?q=libopenstorage%2Fopenstorage+filename%3Ago.mod&type=Code
As the import paths have different meanings between the projects adopting module repos and the non-module repos, materialize the virtual path is a better way to solve the issue, while ensuring compatibility with downstream module users. A textbook example provided by repo
github.com/moby/moby
is here:https://github.com/moby/moby/blob/master/VENDORING.md
https://github.com/moby/moby/blob/master/vendor.conf
In the vendor directory,
github.com/moby/moby
adds the /vN subdirectory in the corresponding dependencies.This will help more downstream module users to work well with your package.
3. Request upstream to do compatibility processing.
The
prometheus/client_golang
have 1049 module-unaware users in github, such as: containerd/cri, gridgentoo/MapD, Mr8/yuanye…https://github.com/search?o=desc&q=prometheus%2Fclient_golang+filename%3Avendor.conf+filename%3Avendor.json+filename%3Aglide.toml+filename%3AGodep.toml+filename%3AGodep.json&s=indexed&type=Code
Summary
You can make a choice when you meet this DM issues by balancing your own development schedules/mode against the affects on the downstream projects.
For this issue, Solution 1 can maximize your benefits and with minimal impacts to your downstream projects the ecosystem.
References
Do you plan to upgrade the libraries in near future?
Hope this issue report can help you ^_^
Thank you very much for your attention.
Best regards,
Kate
The text was updated successfully, but these errors were encountered: