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

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".

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.

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.