Skip to content
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

x/vgo: Doesn't seem to be finding tags correctly #26003

Closed
aarondl opened this issue Jun 21, 2018 · 4 comments

Comments

@aarondl
Copy link

commented Jun 21, 2018

What version of Go are you using (go version)?

go version go1.10.2 linux/amd64 vgo:2018-02-20.1

Does this issue reproduce with the latest release?

Yes (of vgo, haven't updated Go if there's a new release of that).

What operating system and processor architecture are you using (go env)?

Linux amd64.

What did you do?

Tried several different ways to use v3.0.0-rc5 of my library: https://github.com/volatiletech/sqlboiler/tree/v3.0.0-rc5.

I imported:

package main // import "github.com/aarondl/newproject"

import (
	"fmt"
	"os"

	"github.com/volatiletech/sqlboiler/v3/strmangle"
)

func main() {
	_ = strmangle.TitleCase
}

And then used a go.mod that specified v3.0.0-rc5.

I also tried to list the tags available in that repo:

$ vgo list -t github.com/volatiletech/sqlboiler
github.com/volatiletech/sqlboiler
	v1.0.0

What did you expect to see?

I expected to see the tag v3.0.0-rc5 in the go.mod file (and I expected it to stay when I manually coerced it to the correct thing).
I expected to see it correctly list the v1, v2, and v3 tags that exist in that repository, here's some of the tags
that I expected to see:

v1.0.0
v2.0.0
v2.7.1
v2.7.2
v3.0.0-rc4
v3.0.0-rc5

What did you see instead?

I do not see a tag (though I do see the correct commit) in the vgo go.mod file:

module github.com/aarondl/newproject

require (
	github.com/volatiletech/sqlboiler v0.0.0-20180620223943-64005efb0df2
)

I do not see the correct tags listed in the repository:

vgo list -t github.com/volatiletech/sqlboiler
github.com/volatiletech/sqlboiler
	v1.0.0

@gopherbot gopherbot added this to the vgo milestone Jun 21, 2018

@kardianos

This comment has been minimized.

Copy link
Contributor

commented Jun 22, 2018

sqlboiler needs a go.mod file spevifiying a v3 module path. Add that and you should be golden.

@aarondl

This comment has been minimized.

Copy link
Author

commented Jun 22, 2018

Hey @kardianos, thanks for the reply. I'm not sure I understand the suggestion though. I've read about semantic import versioning and Russ's comments about the differences between branches/tags/directories for the purpose of using it. My understanding was that they should be considered equal, so given that, is there still a reason to have to include a go.mod file just to repeat the exact same import path as has been entered in the consumer's go.mod file? Is it because it's a main package at the root level? It also begs the question is it actually checking the contents of each tag for this file and invalidating it (and therefore not outputting it in vgo list -t) because it's missing? How does it even find version v1.0.0 given that that doesn't have a go.mod file?

I was sort of under the impression that this tool was going to work with code that didn't know vgo existed since 90% of the Go ecosystem will be like that for years even after this tool is fully adopted into the toolchain. Is there no way without modifying sqlboiler to make it behave correctly?

I really expected a properly versioned repository that has it's only module at the repository root to "just work".

@aarondl

This comment has been minimized.

Copy link
Author

commented Jun 22, 2018

go will not use any v2 or later tag in a source code repository without first checking that it has a go.mod with a module path declaration ending in that major version (for example, module "my/thing/v2"). Vgo uses that declaration as evidence that the author is using semantic import versioning to name packages within that module. This is especially important for multi-package modules, since the import paths within the module must contain the /v2/ element to avoid referring back to the v1 module.

Ugh. I guess I didn't read close enough. Answered my own question I suppose. The reasoning is unfortunately kind of sound too so I can't even nitpick it too much. Though I think it's definitely a very bad decision to have done it this way. How am I supposed to support non-vgo at the same time? If I change all these import paths to use /v3, it'll break my existing users that don't use vgo since that isn't an import path that can ever possibly exist.

@aarondl aarondl closed this Jun 22, 2018

@kardianos

This comment has been minimized.

Copy link
Contributor

commented Jun 22, 2018

There are point releases for 1.10 and 1.9 that allow working with vX paths. For the this transition, some packages will need to continue to use the v0-rev notation to get versions larger then v1. What you discovered has already been addressed.

@golang golang locked and limited conversation to collaborators Jun 22, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
3 participants
You can’t perform that action at this time.