Importing local go module of external service

Question

The background:

Two Applications - A and B

Application 'A' contains two go.mod files

A/pkg/test/go.mod: (I keep here application specific structures which are gonna be reused by another services willing to integrate)

module A/pkg/test
go 1.14
require (
   some_dependencies vx.x.x
)

A/go.mod: (root module importing pkg/test as local module)

module A
go 1.14
require (
   A/pkg/test v0.0.0
)
replace A/pkg/test => ./pkg/test/

Now Application 'B' would like to re-use Application's A pkg/test package by simply importing it

The Adventage:

This solution lets any integrating services pull only dependencies of pkg/test module instead of importing whole application A tree

Current Solution:

Application 'B' imports pkg/test module of Application 'A' using following go.mod:

module B
go 1.14
require(
   some_dependencies vx.x.x
   A/pkg/test v0.0.0
)
replace A/pkg/test => gitlab.com/A/pkg/test v0.0.0-02345798575346-72cs44671e34

Now I really do not like using commit-timestamp_commit-sha approach here.

The problem:

I would like to use TAGS in order to import A/pkg/test module. Repository A has a tag, say v2.0.0, created. When I replace v0.0.0-02345798575346-72cs44671e34 with v2.0.0, after running go mod tidy/download I am getting following error output:

reading gitlab.com/A/pkg/test/pkg/test/go.mod at revision pkg/test/v2.0.0: unknown revision pkg/test/v2.0.0

The question:

I assume bad package naming/module naming/tagging etc. might lead to such error. The question is what am I missing here in order to make it clear and work?

Answer 1

To take a nested go-modules package within a git repo, just add a tag to the directory that contains the go.mod file - and then append your version.

So in your case, the directory is A/pkg/test and lets say you wanted to use semver v0.0.1 you tag like so:

git tag -a "A/pkg/test/v0.0.1" -m "initial test checkin"
git push origin --tags                            # push all local tags
# git push origin "A/pkg/test/v0.0.1"             # push a single tag

---

Please Note: from the Go wiki Should I have multiple modules in a single repository? - Russ Cox (the creator of vgo i.e. today's go-modules) warns:

For all but power users, you probably want to adopt the usual convention that one repo = one module. It's important for long-term evolution of code storage options that a repo can contain multiple modules, but it's almost certainly not something you want to do by default.

---