Description
I have a specific scenario that makes it hard for me to imagine how the entire Go open source community will have to adapt to vgo.
For those interested to participate in the discussion, please read through the scenario and answer in the context of the scenario so that we don't go off topic. Thanks!
This is my scenario:
I started a new project github.com/marwan-at-work/awesome-go-project
.
Let's say my repo has 35 direct dependencies and 350 transitive dependencies.
Say 25 of my direct dependencies use github.com/dgrijalva/jwt-go
where it’s currently tagged as v3
but does not have v3
in its import path. Therefore, jwt-go
is a transitive dependency and I'm not 100 percent sure which 25 out of 35 direct dependencies use jwt-go
.
When I run vgo build
for the first time it breaks because of the import path
rule. The error says: invalid module: github.com/dgrijalva/jwt-go should be v1, not v3 (v3.1.0)
It's important to note, that I am not trying to upgrade any packages, I am simply running vgo build
for the first time.
So what’s the solution here? If I understand correctly, it’s a 3-step solution:
-
Mr or Ms
dgrijalva
will need to update their repo to include ago.mod
injwt-go
’s root directory to specify a new import path that hasv3
in it. Not that bad. Hopefully they’re online and around to accept PRs. -
Every single one of the 25 dependencies that use
jwt-go
will need to update their source code to usegit.colasdn.top/dgrijalva/jwt-go/v3
(whether manually or through intended tooling). The update itself is not that hard, but having to wait on 25 authors to migrate might take a long while for me to get to step 3: -
I can finally now run
vgo build
.
Now inflate this scenario to the entire Go community. How will we solve this?
Will package users like myself have to wait on my direct dependencies to update their source code, which they themselves will have to wait on their direct dependencies to migrate to vgo?
What is the strategy for this particular scenario?
Thanks