-1

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?

Power
  • 141
  • 1
  • 11
  • 3
    besides the answer below, please read/understand the implications of [semantic versioning](https://semver.org/) - so never start with `v2` - but `v0` and slowly migrate to a mature state of `v1`. `v2` indicates a breaking change that is incompatible with all previous versions - so that switch should be taken very seriously - [read more here](https://blog.golang.org/v2-go-modules). – colm.anseo Sep 29 '20 at 17:35
  • Note that your advantage isn‘t one. – Volker Sep 30 '20 at 07:03
  • @colm.anseo I am aware of that, but thank you for pointing it out and sending over a nice article - might be quite useful for anyone dealing with similar issue – Power Sep 30 '20 at 10:21
  • @Volker would you mind elaborating on how it is not an advantage? This is basically main reason I decided to design it like that and would love to hear counter point. – Power Sep 30 '20 at 10:21
  • @Power Dependencies are cheap. Especially test dependencies which are not compiled into your binary. Go is not Node. – Volker Oct 04 '20 at 08:07
  • @Volker 'test' was just a placeholder name. Normally, what lies under pkg/{package_name} is some common code that would be used across the platform that I am working on currently. Dependencies being cheap doesn't mean they cannot be optimized in terms of size, hence I strongly disagree with you claiming that such solution doesn't bring any adventage. – Power Oct 05 '20 at 08:33

1 Answers1

0

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.

colm.anseo
  • 19,337
  • 4
  • 43
  • 52