Dependency loop between juju/testing several other juju libraries

[gibmat]

A dependency loop exists between juju/testing and the two libraries juju/collections and juju/clock, each of which in turn depend on juju/testing.

Within juju/testing, the use of juju/collections and juju/clock seems to be limited to only the mgo.go file, which imports juju/collections/set and juju/clock.

This was noticed while reviewing dependencies needed to cleanly package LXD for Debian, where each library that LXD depends on must be able to build on its own with a clean set of dependencies. A dependency loop makes this very difficult to accomplish. This may not be a blocking issue as we may have to drop mongodb-specific code because mongodb is no longer in the Debian package archive.

[gibmat]

An even tighter dependency loop was found:

                   juju/testing
                    ^       ^
                    |       |
                    V       V
            juju/errors<--juju/utils

If there's any way to make that dependency graph a DAG, it would make life much easier when individual libraries need to be packaged. 😄

(Helps if I draw the arrows correctly....)

[gibmat]

A few observations from my work while packaging this library for Debian:

• I've ignored mgo.go & friends, as mongodb doesn't currently exist in the Debian archive. That also nicely cuts the dependency loop between testing and collections and clock; it still exists and should be fixed, but is not a blocking issue.

• The use of the utils library within testing consists of calls to several small helper functions:

  • utils.ShQuote()
  • utils.SetHome()
  • utils.Home()

  Those are all basically one-liners, so I think it would be easy enough to just replace those calls into utils with the actual code. Doing so would break that dependency loop.

• The dependency on the errors library is a bit stickier. There are several uses of the functions errors.Trace() and errors.New(). For the time being, I've just commented out affected tests (ugh) and adjusted the code to return the raw err, rather than wrapping it in Trace(). The code involved with use of errors is more complicated than utils, so I am going to have to rely on the actual authors of the code to cleanly break this loop.

The good news is that, with the above changes, I've been able to successfully build the following juju libraries without any dependency loops: clock, cmd, collections, errors, mutex, and utils.