Awful dependency problem caused by romulus

[roger peppe]

On 19 May 2016 at 07:02, David Cheney <david.cheney at canonical.com> wrote:
> Hello,
>
> github.com/juju/juju/cmd/juju/commands:
>   github.com/juju/romulus/cmd/commands:
>     github.com/juju/romulus/cmd/setplan: <<<<<<<<<<<<<<<<<<<<<
>       github.com/juju/juju/api/service:
>       github.com/juju/juju/cmd/modelcmd:
>
> cmd/juju depends on the romulus repository, and the romulus repository
> depends on juju.
>
> This is terrible. It means we _cannot_ change the public api of the
> juju that romulus depends on because then juju won't compile, and we
> cannot land the fix to romulus without breaking juju.

I agree that this is unfortunate, but "cannot" is a strong word. I believe
that there is a (somewhat painful) workaround for this - we've been in
similar situations
before.

Say you want to change the public API of juju in a backwardly incompatible
way. Here's how you can do it.

First change the API and fix romulus to work with the new API, without
merging either change into their repos.

Then push the romulus change to the romulus repo in a *feature branch*
rather onto master. Tests will not pass in this branch because it depends
on as-yet-to-be-landed changes in juju, but the code is now available in
the romulus repo.

Then propose the Juju changes with the feature-branch revision
of romulus as a dependency. Tests should pass OK because godeps
doesn't care which branch its dependencies are pulled from.

Once that's landed, land the romulus changes in romulus master
depending on the just-landed changes in juju.

Then update juju to use the latest romulus dependency.

As for the cyclic dependency itself, perhaps there's an argument for
moving the main juju command into a separate repo (or everything *but*
the juju main command into a separate repo) so that it's possible
to include externally implemented commands without creating a cycle.

  cheers,
    rog.

> Casey, please fix this immediately. Either juju depends on romulus, or
> romulus depends on juju, but at the moment they both depend on each
> other and that is a showstopper,
>
> Thanks
>
> Dave
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev