Skip to content

split into two packages; apparmor only imported by optional package

Latest
Compare
Choose a tag to compare
@thepudds thepudds released this 14 Apr 15:36
· 3 commits to main since this release

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/[email protected]
$ 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
)