You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to use Optuna w/ the PytorchLightningPruningCallback in a code-base with a pre-2.0 version of Pytorch Lightning. As it stands, I need to vendor the callback to support using the pytorch_lightning package instead of lightning.pytorch.
The callback imports lightning.pytorch which is the 2.0+ approved method for doing so. Using the pytorch-lightning package (which has feature parity but is the backwards-compatible method) does not work. There is no fundamental reason, as far as Optuna is concerned, that the pruning callback couldn't try both packages.
Suggestion
Attempt to import lightning.pytorch. If that is not successful, try to import pytorch_lightning. If that doesn't work, give up.
The diff suggests there were no material changes to the PytorchLightning compatibility between v3.6.0 and v4.0.0.
#137 previously suggested changing from lightning.pytorch to pytorch_lightning, which was rejected. I think supporting both packages is reasonable, however.
The text was updated successfully, but these errors were encountered:
Thank you for creating the feature request and sharing the possible solution. Let me leave my thoughts on this integration module to discuss this feature. I think optuna-integration repo has tested only the latest stable version of dependent packages. So, we cannot test the backwards compatibility of lightning enough using the current CI. In addition, lightning sometimes breaks backward compatibility aggressively, so the older version support requires much more work to maintain this module.
Motivation
I would like to use Optuna w/ the PytorchLightningPruningCallback in a code-base with a pre-2.0 version of Pytorch Lightning. As it stands, I need to vendor the callback to support using the
pytorch_lightning
package instead oflightning.pytorch
.The callback imports
lightning.pytorch
which is the 2.0+ approved method for doing so. Using thepytorch-lightning
package (which has feature parity but is the backwards-compatible method) does not work. There is no fundamental reason, as far as Optuna is concerned, that the pruning callback couldn't try both packages.Suggestion
Attempt to import
lightning.pytorch
. If that is not successful, try to importpytorch_lightning
. If that doesn't work, give up.Current code:
Suggested Code:
Additional context (optional)
optuna-integration
version:3.6.0
.The diff suggests there were no material changes to the PytorchLightning compatibility between v3.6.0 and v4.0.0.
#137 previously suggested changing from
lightning.pytorch
topytorch_lightning
, which was rejected. I think supporting both packages is reasonable, however.The text was updated successfully, but these errors were encountered: