Awful dependency problem caused by romulus

[Casey Marshall]

Matty, this sounds like a great idea.

Dave, I understand and thanks for clarifying. Please give us some time to
coordinate the package relocation in our next iteration (begins next week).

Thanks,
Casey


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

> 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
> >> >
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160519/19a41615/attachment.html>