Make other OARS plugins pip dependencies

[bmtcril]

I think we can make installation easier by simple requiring the correct versions of the other plugins in this one so they automatically get installed. They'll still need to be enabled manually, but it should save a few steps.

[Ian2012]

What versioning system will we use for those plugins?

Is it the same as tutor or will be an independent one?

Is anything blocking this issue?

[bmtcril]

I've talked about this with a few people and am still not settled on a best solution. I'd be interested in hearing more opinions. Here are some thoughts:

• It should be possible to run the OARS plugin without the Ralph, ClickHouse, or Superset plugins (for example if someone is using ClickHouse Cloud or a managed Superset)
• It is likely that tutor-contrib-oars will need to version when changes happen in the other plugins, but not the other way around (upgrading Superset is likely to require changes in OARS, but those OARS changes are unlikely to require changes to tutor-contrib-clickhouse)
• It is likely that people will want to upgrade things separately (getting new reports from OARS is unlikely to require a ClickHouse upgrade at the same time, the latter is potentially risky and I don't think we should block the former on it unless there's a technical reason to do so)
• Maintaining version compatibility between all of these different repos is potentially challenging, but probably no different than the usual Python dependency management if we are careful

So my best current thought is that we should not actually make those other plugins hard dependencies of this one (and close this ticket), but I'm on the fence about how to version them together. There's value in keeping them all at the same minor version, and if any component has a breaking change doing a major version bump on them all. I think at least that way we'll be able to tell which versions are compatible at a glance. That would still be a manual process for the operators to decide which versions of each plugin to install in their Tutor environment, however.

@mariajgrimaldi @pomegranited I'd love to hear your thoughts as well!

[Ian2012]

With that being the case, we should use the same versioning system as tutor, so the plugins share a major version, and when there is a breaking change bump them all (as you said), and it's important to install the plugins as dependencies and use variables as established by the tutor standard to define if you want to run X service.

RUN_LMS, RUN_MYSQL, etc

This will also help us to refactor the code for production usage with all the different cases in which each service can communicate with the domain and not by the service name.

Like in those cases, it would be way easier to implement optimizations in which if superset is running in the cluster use the service name: #35 (comment)

cc @mariajgrimaldi

[Ian2012]

@bmtcril This one can be closed