[ENH] resolving partial duplications between sktime and skpro

[fkiraly]

We should think about how best to resolve the partial duplications between sktime and skpro related to probability distributions and metrics, in terms of end state and transition strategy. Quickly summarized:

• skpro has a distributions module, which is at the moment an improvement and evolution above sktime's proba module.
• in sktime, distributions are used in probabilistic forecasting currently, but could soon also be used in time series anomaly and event modelling, or probabilistic time series regression.
• skpro has some features and specific distributions which do not exist in sktime, but can be directly useful. It has evolved, in terms of functionality and maturity, beyond what is available in sktime.
• skpro and sktime have a similar module for probabilistic regression metrics, used in evaluation and tuning in both packages.
• the interfaces in sktime probabilistic forecasting and skpro probabilistic regression share a number of logic elements, especially method interfaces, boilerplate, and dispatch defaults. The same logic would also be attache to probabilistic time series regressors, if created.

For end state, one could imagine:

• sktime takes a dependency on skpro and uses distributions and/or metrics from the latter. This is directly possible since the improved skpro distributions are fully API compliant.
• skpro takes a dependency on sktime - in this case, the modules would have to be moved to sktime and replace the current state of modules related to distributions and/or metrics
• the status quo, although that would not resolve duplications

For transition, deprecation will be necessary, as an abrupt switch to imports of objects while removing the original import locations of distributions etc will break user code.

• an option is replacing actual objects with imports of the same name in the same locations. [MNT] replace proba module by skpro - diagnostic to ensure API consistency #6393 shows that this would work. The question is whether this could break user code. I cannot see this, but it does not mean it's true.
• another option is dispatching for a transition period - leaving objects as they are, but replacing them with imports if skpro is present. This is done for a transition period. Might be safer than the first option.

[frthjf]

How about sktime taking an optional dependency on skpro? As far as I can tell, this is already quite common in sktime (e.g. require Tensorflow for MLP models etc.). As a user, it would make sense to me to see an error asking me to install skpro if I wanted to use probabilistic features in sktime. The import redirection may be useful in a transition period but I would aim to remove it longer term to avoid confusion (e.g. import sktime.tensorflow as tf would make we wonder what I am looking at).

[fkiraly]

How about sktime taking an optional dependency on skpro?

That is a valid target state, too.

It already does depend optionally, for reduction using probabilistic regressors to create probabilistic forecasters.

However, currently the probabilistic forecasting functionality in forecasters is a core features of sktime. Would we make skpro optional and deduplicate, then that would imply that probabilistic forecasting is an optional feature and available only if skpro is installed.
This is technically feasible, my worry about this is that very common functionality would no longer be onboard by default - it is currently available whenever sktime with minimal dependencies is present. So I excluded this mentally, not with any ulterior intention of course. I agree it is a significant option to consider pros/cons.

[fkiraly]

Any opinions on pros/cons, @frthjf?

[frthjf]

I think the option of sktime taking skpro as required dependency as implemented in #6393 is reasonable given that sktime arguably relies on it for "very common functionality". What might be a problem, is that any dependency added to skpro becomes a dependency in sktime. One way around that would be to move the distributions code into a separate repo and include it as a submodule in both sktime and skpro, but I am unsure if that's worth the trouble.

[fkiraly]

What might be a problem, is that any dependency added to skpro becomes a dependency in sktime.

Yes - although not as large as it could be, as currently the skpro dependencies are exactly those of sktime.
(soft dependencies wildly differ, but these are optional and not required by sktime)

It might become an issue at release though, when bounds are bumped, although I would think that less of a problem.

[frthjf]

Yes, given that both projects are under the sktime organization, the dependency management should be workable.