Awful dependency problem caused by romulus

[David Cheney]

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
>
>