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
