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 <[email protected]> wrote: > Thanks Matty! > > On Thu, May 19, 2016 at 6:51 PM, Matthew Williams > <[email protected]> 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 < > [email protected]> > > 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 > >> <[email protected]> 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 > >> > <[email protected]> > >> > wrote: > >> >> > >> >> On Thu, May 19, 2016 at 5:04 PM, roger peppe > >> >> <[email protected]> > >> >> wrote: > >> >> > On 19 May 2016 at 07:02, David Cheney <[email protected]> > >> >> > 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 > >> >> >> [email protected] > >> >> >> Modify settings or unsubscribe at: > >> >> >> https://lists.ubuntu.com/mailman/listinfo/juju-dev > >> >> > >> >> -- > >> >> Juju-dev mailing list > >> >> [email protected] > >> >> Modify settings or unsubscribe at: > >> >> https://lists.ubuntu.com/mailman/listinfo/juju-dev > >> > > >> > > > > > >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
