Awful dependency problem caused by romulus

[Matthew Williams]

Really sorry about this Dave, I'd not realised just how much they relied on
each other. Surely there's an argument for romulus being merged into core?

On Thu, May 19, 2016 at 8:55 AM, David Cheney <david.cheney at canonical.com>
wrote:

> On Thu, May 19, 2016 at 5:04 PM, roger peppe <roger.peppe at canonical.com>
> wrote:
> > 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.
>
> Or I could just land the commits directly. I guess it depends if we
> want to play the CI game or not. My point is creating loops like this
> means we have to reach for even more creative measures to mitigate
> them.
>
> To be clear, this is a big mistake, it's fine for juju to depend on a
> project, we currently depend on 72 projects. What is not ok is for
> that project to then depend back on juju, that is poor software
> engineering.
>
> > 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.
>
> I'd very much like to see this. It's clear that the juju command is
> going to have to serve multiple masters, and by breaking it off into a
> separate project this would force us (juju) to create a supported
> public API which we currently do not have.
>
> >
> >   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
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160519/3a926103/attachment-0001.html>