Awful dependency problem caused by romulus

[David Cheney]

Thanks Matty!

On Thu, May 19, 2016 at 6:51 PM, Matthew Williams
<matthew.williams at canonical.com> wrote:
> Yeah - the mistake we made was starting with pure intentions but over time
> starting to think of it as just another part of core. I'll have to discuss
> it with Casey when he's up
>
> On Thu, May 19, 2016 at 9:47 AM, David Cheney <david.cheney at canonical.com>
> wrote:
>>
>> I think that would be the best solution, I don't see how we can undo
>> the dependencies between cmd/juju and romulus -- they're so tightly
>> coupled they should probably live in the same repository.
>>
>> On Thu, May 19, 2016 at 6:45 PM, Matthew Williams
>> <matthew.williams at canonical.com> wrote:
>> > 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
>> >
>> >
>
>