sktime / pytorch-forecasting

Time series forecasting with PyTorch
https://pytorch-forecasting.readthedocs.io/
MIT License
4.01k stars 635 forks source link

[MNT] maintenance & handover items for integration with sktime org #1592

Open fkiraly opened 3 months ago

fkiraly commented 3 months ago

We are currently planning a maintenance handover of pytorch-forecasting to sktime. Both packages will remain separate, with pytorch-forecasting on the "models" level, and sktime 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

handover items

roadmap items for consideration or wishlist

fkiraly commented 3 months ago

FYI sktime developers who have worked on the integration, @benheid, @fnhirwa, @geetu040, @xinyuwuu, @yarnabrina

fkiraly commented 3 months ago

At the very start, we need to get the CI run again. Reason for failures:

Suggested measures:

Once this is done, release 1.1.0.

Next, dependency management:

XinyuWuu commented 3 months ago

Fixing tutorial notebooks is also very important: https://github.com/jdb78/pytorch-forecasting/pull/1599

fkiraly commented 3 months ago

of course - we won't know whether we fixed them though if the CI does not run

XinyuWuu commented 3 months ago

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.

fkiraly commented 3 months ago

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.

XinyuWuu commented 3 months ago

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.

XinyuWuu commented 3 months ago

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.

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.