Open fkiraly opened 3 weeks ago
FYI sktime developers who have worked on the integration, @benheid, @fnhirwa, @geetu040, @xinyuwuu, @yarnabrina
At the very start, we need to get the CI run again. Reason for failures:
numpy 2
incompatibility at missing version bound, #1594optuna >= 3.3.0
incompatibility at missing version bound, #1595Suggested measures:
pip
from poetry
, this makes work on CI easier https://github.com/jdb78/pytorch-forecasting/pull/1593black
, and change linting check to only look at changed files https://github.com/jdb78/pytorch-forecasting/pull/1597, https://github.com/jdb78/pytorch-forecasting/pull/1598Once this is done, release 1.1.0.
Next, dependency management:
python 3.11, 3.12
numpy
, then optuna
, fix incompatibilitiesFixing tutorial notebooks is also very important: https://github.com/jdb78/pytorch-forecasting/pull/1599
of course - we won't know whether we fixed them though if the CI does not run
Regarding the dependency management, maybe we should not minimize core dep set.
Comparing to torch
, lightning
, optuna
, other packages are too small to make a difference to installation time.
It could be a disaster if a lot a time has been spent to train the model, and then some soft dependency error comes out.
So maybe we should make sure that users have almost all the functionalities with the core dep set.
Agree, though even small dependencies pose a risk of reducing the degree of interoperability on the level of dependencies. Suppose you have small_package
which has a very restrictive dependency set, or small_package2
which is the only dependency that never upgrades to numpy 2
or python 3.12
.
Further, I wonder about how central optuna
is here. It is important for tuning, but its purpose seems extraneous to the primary defining topic of deep learning based forecasters.
Further, I wonder about how central
optuna
is here. It is important for tuning, but its purpose seems extraneous to the primary defining topic of deep learning based forecasters.
It's only used in pytorch_forecasting/models/temporal_fusion_transformer/tuning.py to tune TemporalFusionTransformer. So I guess it's not so central.
Agree, though even small dependencies pose a risk of reducing the degree of interoperability on the level of dependencies. Suppose you have
small_package
which has a very restrictive dependency set, orsmall_package2
which is the only dependency that never upgrades tonumpy 2
orpython 3.12
.
Yeah, that could be a problem. We could have two dep sets core
and compatible
and put those packages that don't fit in well in compatible
set.
We are currently planning a maintenance handover of
pytorch-forecasting
tosktime
. Both packages will remain separate, withpytorch-forecasting
on the "models" level, andsktime
providing framework integration.This issue is to plan urgent maintenance items and handover (to
sktime
maintenance model).Community input on todos and wishlist is also appreciated, e.g., what are "burning" items, suggested priorities.
Maintenance items
optuna
ormatplotlib
, not needed for NN models core)handover items
roadmap items for consideration or wishlist