V4 Vanity URL

[asim]

So we're looking to move our import path to go-micro.dev. Part of that means a backwards incompatible change, meaning we can't just do it in a v3, we have to move to a v4. Otherwise it gets really tricky. Along with that, obviously each version brings its own changes.

The history thus far

• V1 marked versioning of a 4 year old project
• V2 moved go mod and gRPC by default
• V3 separated go-micro from micro
• V4 non github specific aka go-micro.dev

If anyone has ideas for V4 let me know. One major change I'm thinking about is putting the entire API into version specific dirs, which I was hugely opposed to in the past but now as there are so many packages, it feels like this maybe needs to be scoped.

One potential example

go-micro/
   cmd/
   examples/
   plugins/
   services/
   v3/
   v4/

Another is to scope all packages under service/

go-micro/
   cmd/
   examples/
   plugins/
   service/
     auth/
     broker/
     cache/
     client/
     server/
     store/
     ...
   services/

[simon28082]

Now About plugins Never compatible with it?
Example:

import loggerp "github.com/asim/go-micro/plugins/logger/logrus/v3"
// error, type error
logger.DefaultLogger = loggerp.NewLogger(loggerp.WithLogger(l))

but I not found go-micro.dev/v4 plugins about v4

[bootfirst]

First, I prefer the second way. 'v' is better maintained by the version control system.
BTW, the plugins module name should change to "go-micro.dev/v4" too. And some examples too.

[simon28082]

go get: go-micro.dev/v4/plugins/auth/jwt@v1.18.0: parsing go.mod:
module declares its path as: github.com/micro/go-micro
but was required as: go-micro.dev/v4/plugins/auth/jwt

[AuditeMarlow]

go get: go-micro.dev/v4/plugins/auth/jwt@v1.18.0: parsing go.mod: module declares its path as: github.com/micro/go-micro but was required as: go-micro.dev/v4/plugins/auth/jwt

The Module name for the JWT plugin is github.com/asim/go-micro/plugins/auth/jwt/v4.

[asim]

I've migrated the main source to go-micro.dev/v4 however submodules seem to be much trickier using that. I can't quite figure out the go-import for it. So for now plugins stay as the GitHub path until we find a solution.

[xpunch]

Unable to install protoc-gen-micro/v4

go install go-micro.dev/cmd/protoc-gen-micro/v4@latest
go: downloading go-micro.dev/cmd/protoc-gen-micro/v4 v4.1.0
go install: go-micro.dev/cmd/protoc-gen-micro/v4@latest: go-micro.dev/cmd/protoc-gen-micro/v4@v4.1.0: parsing go.mod:
        module declares its path as: go-micro.dev/v4
                but was required as: go-micro.dev/cmd/protoc-gen-micro/v4

[xpunch]

Before migrated to v4, you should release an final release for v3. Currently the latest v3 version is 3.6.0, which is not compatible with some v3 plugins, people who cannot migrate to v4 right now may still need an stable go-micro v3.

[asim]

I'm not really sure what's incompatible so happy to see someone else do the work for that. I'm just trying to push forward with a non GitHub import right now.

[xpunch]

All v3 plugins cannot be install by go get.

go get github.com/asim/go-micro/plugins/auth/jwt/v3@latest
go get: module github.com/asim/go-micro@latest found (v1.18.0), but does not contain package github.com/asim/go-micro/plugins/auth/jwt/v3

go get github.com/asim/go-micro/plugins/auth/jwt/v3
go get: module github.com/asim/go-micro@latest found (v1.18.0), but does not contain package github.com/asim/go-micro/plugins/auth/jwt/v3

Old plugins can only be install by given version.

go get github.com/asim/go-micro/plugins/auth/jwt/v3@v3.0.0-20210712061837-0532fd9de8ae
go: downloading github.com/asim/go-micro/plugins/auth/jwt/v3 v3.0.0-20210712061837-0532fd9de8ae
go get: added github.com/asim/go-micro/plugins/auth/jwt/v3 v3.0.0-20210712061837-0532fd9de8ae

[asim]

Not really sure what that's about. Nothing changed on the v3 tags

[asim]

@xpunch how about I add you as a maintainer and you sort of the v3 issues?

[xpunch]

@asim OK, I can do that.

[asim]

@xpunch added you as a collaborator. Please go ahead and fix.

[xpunch]

Mapping versions to commits

If a module is defined in a subdirectory within the repository, that is, the module subdirectory portion of the module path is not empty, then each tag name must be prefixed with the module subdirectory, followed by a slash. For example, the module golang.org/x/tools/gopls is defined in the gopls subdirectory of the repository with root path golang.org/x/tools. The version v0.4.0 of that module must have the tag named gopls/v0.4.0 in that repository.

Currently all plugins and tools modules are untagged, so go get may download module source code and metadata directly from version control repository. That's why all v3 plugins will end with version like "v3.0.0-20211013085205-7136c61dbdde".
The best way to fix this is to create tags for all plugins based on commit d9a6fae which is the latest commit before migrated to go-micro.dev.
If you agree with this solution(I've tested it in example), I will run following commands for every plugins.

git tag v3.7.0 -- d9a6faeb7a763b461f9b8e93cc07a7bf4bc03e5b
...
git tag plugins/auth/jwt/v3.7.0 -- d9a6faeb7a763b461f9b8e93cc07a7bf4bc03e5b
git push origin v3.7.0 plugins/auth/jwt/v3.7.0 ...

After doing this, users who want to use go-micro v3, can get go-micro and plugins by following commans:

go get github.com/asim/go-micro/v3@v3.7.0
go get github.com/asim/go-micro/plugins/auth/jwt/v3@v3.7.0

[asim]

Sounds good. We had a release script which I think was doing similar https://github.com/asim/go-micro/blob/master/plugins/release.sh. If that works please use it, otherwise amend.

[xpunch]

Currently v3 plugins and tools were released with v3.7.0, but we cannot update README.md or do bug fixing for v3.
The proposal that move into specific dirs may break compatibility, should we create branch v3 based on d9a6fae to handle bug fixing of v3? V4 can have a lot of backwards incompatible changes, and v3 can be still maintained.
go-micro v2 is still used by a lot of projects, according to some bug fixing, the latest v2.9.1 may still have some bugs, but there is no way to fixing that.

[asim]

So you're right. There's large user bases at each version and the maintenance in that regard is hard. We either need the versioned subdirectories which go modules can support or branches. I think branches may be cleaner.

[asim]

If it makes sense go ahead and create v2 and vv3 branches

[asim]

You've just made me realise. The v4 submodules were not working with the vanity URL because they were not tagged. I may have to retest that

[xpunch]

I've tested go-micro.dev/v4 import issue(#2321), seams the vanity url of go-micro.dev/v4 is not working fine.

curl -v https://go-micro.dev/v4

<html>
<head><title>302 Found</title></head>
<body>
<center><h1>302 Found</h1></center>
<hr><center>nginx/1.17.3</center>
</body>
</html>

Should be like:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width" />
    <meta name="go-import" content="go-micro.dev/v4 git https://github.com/asim/go-micro">
    <meta name="go-source" content="go-micro.dev/4 https://github.com/asim/go-micro https://github.com/asim/go-micro/tree/master{/dir} https://github.com/asim/go-micro/blob/master{/dir}/{file}#L{line}">
    <title>Go Micro</title>
  </head>

  <body>
	Redirecting you to the <a href="https://github.com/asim/go-micro">go micro</a>
  </body>
</html>

[asim]

When go get is called its called with ?go-get=1 as the param, when this happens the go-import is served

[asim]

So now if you curl you'll see

curl https://go-micro.dev
<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width" />
    <meta name="go-import" content="go-micro.dev/v4 git https://github.com/asim/go-micro">
    <meta name="go-source" content="go-micro.dev/4 https://github.com/asim/go-micro https://github.com/asim/go-micro/tree/master{/dir} https://github.com/asim/go-micro/blob/master{/dir}/{file}#L{line}">
    <meta http-equiv="refresh" content="0;URL='https://github.com/asim/go-micro'" />
    <title>Go Micro</title>
  </head>

  <body>
        Redirecting you to the <a href="https://github.com/asim/go-micro">Github</a>.
  </body>
</html>

[asim]

Using nginx, here's the rules

        root /web/go-micro/html;

        location ~ ^/plugins/(.*)/(v[0-9].*) {
                if ($args = "go-get=1") {
                        add_header Content-Type text/html;
                        return 200 '<meta name="go-import" content="$host/plugins/$1/$2 git https://github.com/asim/go-micro.git">';
                }
        }

        location ~ ^/(.*) {
                if ($args = "go-get=1") {
                        add_header Content-Type text/html;
                        return 200 '<meta name="go-import" content="$host/$1 git https://github.com/asim/go-micro.git">';
                }
        }

        location ~ ^/(.*)$ {
                if ($args = "go-get=1") {
                        add_header Content-Type text/html;
                        return 200 '<meta name="go-import" content="$host/$1 git https://github.com/asim/go-micro.git">';
                }
        }

[xpunch]

Now it works. #2321 and #2271 can be closed.

[asim]

Now that we've fixed that. Next question, can vanity urls be used as part of modules like the plugins, examples, etc?

[charlesvhe]

install protoc-gen-micro not work:

go install go-micro.dev/v4/cmd/protoc-gen-micro@latest

go install: go-micro.dev/v4/cmd/protoc-gen-micro@latest: go-micro.dev/v4/cmd/protoc-gen-micro@v1.18.0: parsing go.mod:
module declares its path as: github.com/micro/go-micro
but was required as: go-micro.dev/v4/cmd/protoc-gen-micro

[xpunch]

@charlesvhe you can try:

go install github.com/asim/go-micro/cmd/protoc-gen-micro/v4@latest

[asim]

The latest with vanity URL is not tagged. I want to try get as much under the vanity URL as possible and then tag

[asim]

Moved cmd/micro to be under the vanity url also now @AuditeMarlow

[asim]

I wish we could get plugins under a vanity url. Go really sucks sometimes.

[AuditeMarlow]

Moved cmd/micro to be under the vanity url also now @AuditeMarlow

go get go-micro.dev/v4/cmd/micro@latest now results in the following:

go: downloading go-micro.dev/v4/cmd/micro v1.18.0
go install: go-micro.dev/v4/cmd/micro@latest: go-micro.dev/v4/cmd/micro@v1.18.0: parsing go.mod:
        module declares its path as: github.com/micro/go-micro
                but was required as: go-micro.dev/v4/cmd/micro

I think this requires a tag as mentioned before in this thread, but I'm not sure what to tag exactly.

[asim]

https://github.com/asim/go-micro/releases/tag/v4.3.0

[asim]

Not sure what's going on with @latest but @v4.30 or @master works