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.che...@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.willi...@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.che...@canonical.com> > > wrote: > >> > >> On Thu, May 19, 2016 at 5:04 PM, roger peppe <roger.pe...@canonical.com > > > >> wrote: > >> > On 19 May 2016 at 07:02, David Cheney <david.che...@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@lists.ubuntu.com > >> >> Modify settings or unsubscribe at: > >> >> https://lists.ubuntu.com/mailman/listinfo/juju-dev > >> > >> -- > >> Juju-dev mailing list > >> Juju-dev@lists.ubuntu.com > >> Modify settings or unsubscribe at: > >> https://lists.ubuntu.com/mailman/listinfo/juju-dev > > > > >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
