<div dir="ltr">Matty, this sounds like a great idea.<div> </div><div>Dave, I understand and thanks for clarifying. Please give us some time to coordinate the package relocation in our next iteration (begins next week).<div> </div><div>Thanks,</div><div>Casey</div><div> </div></div></div><div class="gmail_extra"> <div class="gmail_quote">On Thu, May 19, 2016 at 2:57 AM, David Cheney <<a href="mailto:david.cheney@canonical.com" target="_blank">david.cheney@canonical.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks Matty! On Thu, May 19, 2016 at 6:51 PM, Matthew Williams <div class="HOEnZb"><div class="h5"><<a href="mailto:matthew.williams@canonical.com">matthew.williams@canonical.com</a>> 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 <<a href="mailto:david.cheney@canonical.com">david.cheney@canonical.com</a>> > 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 >> <<a href="mailto:matthew.williams@canonical.com">matthew.williams@canonical.com</a>> 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 >> > <<a href="mailto:david.cheney@canonical.com">david.cheney@canonical.com</a>> >> > wrote: >> >> >> >> On Thu, May 19, 2016 at 5:04 PM, roger peppe >> >> <<a href="mailto:roger.peppe@canonical.com">roger.peppe@canonical.com</a>> >> >> wrote: >> >> > On 19 May 2016 at 07:02, David Cheney <<a href="mailto:david.cheney@canonical.com">david.cheney@canonical.com</a>> >> >> > wrote: >> >> >> Hello, >> >> >> >> >> >> <a href="http://github.com/juju/juju/cmd/juju/commands" rel="noreferrer" target="_blank">github.com/juju/juju/cmd/juju/commands</a>: >> >> >> <a href="http://github.com/juju/romulus/cmd/commands" rel="noreferrer" target="_blank">github.com/juju/romulus/cmd/commands</a>: >> >> >> <a href="http://github.com/juju/romulus/cmd/setplan" rel="noreferrer" target="_blank">github.com/juju/romulus/cmd/setplan</a>: <<<<<<<<<<<<<<<<<<<<< >> >> >> <a href="http://github.com/juju/juju/api/service" rel="noreferrer" target="_blank">github.com/juju/juju/api/service</a>: >> >> >> <a href="http://github.com/juju/juju/cmd/modelcmd" rel="noreferrer" target="_blank">github.com/juju/juju/cmd/modelcmd</a>: >> >> >> >> >> >> 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 >> >> >> <a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a> >> >> >> Modify settings or unsubscribe at: >> >> >> <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a> >> >> >> >> -- >> >> Juju-dev mailing list >> >> <a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a> >> >> Modify settings or unsubscribe at: >> >> <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a> >> > >> > > > </div></div></blockquote></div> </div>