split into two packages; apparmor only imported by optional package

This v0.4.0 tag is intended to show a scenario that is different from the example in #52296.

In this alternative, a different hypothetical foobar module has one package that only imports logrus, and a second optional package that also imports apparmor from containerd.

In other words, this is showing a different hypothetical package-level graph where apparmor is part of the module-level graph but apparmor is not in the package-level graph if a client only imports a subset of the foobar packages without directly or indirectly importing our optional package.

We are excluding the "bad" v1.7.1, v1.8.0, and v1.8.1 versions of logrus in our foobar go.mod, and as a result our foobar go.mod requires logrus v1.7.0.

The good news is that a new client of our foobar module that does not import our optional package now ends up with logrus v1.7.0, which was our desired outcome:

$ cat foobarclient.go
package foobarclient

import foobar "github.com/thepudds/test-go-mod-52296-a"

var F = foobar.Foobar

$ cat go.mod
module test-go-mod-52296-a-client

go 1.18

require github.com/thepudds/test-go-mod-52296-a v0.4.0

require (
        github.com/sirupsen/logrus v1.7.0 // indirect
        golang.org/x/sys v0.0.0-20211216021012-1d35b9e2eb4e // indirect
)

---

One caveat however is if foobar was a library that went through these changes, a pre-existing client of our v0.3.0 would have already recorded the undesirable logrus v1.8.1 in its own go.mod, and the client would not magically have its version of logrus downgraded just by upgrading to our v0.4.0. If the client started by depending on our v.0.3.0 with a go.mod similar to:

$ cat go.mod
module test-go-mod-52296-a-client

go 1.18

require github.com/thepudds/test-go-mod-52296-a v0.3.0   // NOTE: v0.3.0 has a single package 

require (
        github.com/containerd/containerd v1.6.2 // indirect
        github.com/sirupsen/logrus v1.8.1 // indirect
        golang.org/x/sys v0.0.0-20211216021012-1d35b9e2eb4e // indirect
)

...and then if the client just upgrades to our v0.4.0 and runs go mod tidy, they end up with a go.mod similar to the following, which still depends on the undesirable logrus v1.8.1:

$ go get github.com/thepudds/test-go-mod-52296-a@v0.4.0
$ go mod tidy
$ cat go.mod
module test-go-mod-52296-a-client

go 1.18

require github.com/thepudds/test-go-mod-52296-a v0.4.0

require (
        github.com/sirupsen/logrus v1.8.1 // indirect
        github.com/stretchr/testify v1.7.0 // indirect
        golang.org/x/sys v0.0.0-20211216021012-1d35b9e2eb4e // indirect
        gopkg.in/yaml.v3 v3.0.0-20210107192922-496545a6307b // indirect
)

exclude logrus v1.8.1, v1.8.0, v1.7.1. We use logrus v1.7.0, but a client ends up with logrus v1.8.1

In our foobar go.mod, we manually excluded versions of logrus we did not want:

exclude (
	github.com/sirupsen/logrus v1.7.1
	github.com/sirupsen/logrus v1.8.0
	github.com/sirupsen/logrus v1.8.1
)

go mod tidy then updates our foobar go.mod to require logrus v1.7.0, which is the desired version.

However, a client of foobar still gets logrus v1.8.1, which is not desired:

$ cat foobarclient.go
package foobarclient

import foobar "github.com/thepudds/test-go-mod-52296-a"

var F = foobar.Foobar

$ cat go.mod
module test-go-mod-52296-a-client

go 1.18

require github.com/thepudds/test-go-mod-52296-a v0.3.0

require (
        github.com/containerd/containerd v1.6.2 // indirect
        github.com/sirupsen/logrus v1.8.1 // indirect
        golang.org/x/sys v0.0.0-20211216021012-1d35b9e2eb4e // indirect
)

Full Changelog: v0.2.0...v0.3.0

import apparmor from containerd, pushing logrus to v1.8.1 (not desired)

This is the ending state of the concrete example in the opening comment golang/go#52296 (comment).

Two minor differences that don't affect the overall result:

1. We changed the grouping of the require directives in go.mod so that they have the more standard Go 1.17+ grouping.
2. In preparation for a later step, we changed from a main package to a library.

Full Changelog: v0.1.0...v0.2.0

import only logrus, require logrus v1.7.0

v0.1.0

initial state: import only logrus, require logrus v1.7.0