Skip to content

Conversation

fkiraly
Copy link

@fkiraly fkiraly commented Jun 14, 2025

I think we should make scikit-learn an optional dependency of gfo.

Otherwise, currently, hyperactive depends on gfo, and gfo on scikit-learn, making it a required dependency - even though it is used only in a small number of places.

This PR "isolates" scikit-learn in the sense that:

  • imports do not happen on module level where possible
  • scikit-learn is installed as a test dependency instead of as a core dependency

Also does some other minor things:

  • remove unused imports

epsilon=0.03,
distribution="normal",
n_neighbours=3,
estimators=[
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mutable defaults should never be used - general python thing, not specific to sklearn isolation

@SimonBlanke
Copy link
Owner

This would lead to a worse "out of the box" experience for the user, since using these optimizers will raise an error if sklearn is not already installed, right? Sklearn is not an optional dependency, but is (at the moment) required for the use of the supported optimization algorithms of this package.
But to minimize dependencies I started to natively implement the required estimators in this module:
https://github.com/SimonBlanke/Gradient-Free-Optimizers/tree/master/src/gradient_free_optimizers/_estimators

This way sklearn can be a true optional dependency.

@fkiraly
Copy link
Author

fkiraly commented Jul 31, 2025

This would lead to a worse "out of the box" experience for the user, since using these optimizers will raise an error if sklearn is not already installed, right?

Hm, yes, if we move scikit-learn to the optional dependency set, you are right.

However, if we do not change pyproject.toml, I believe nothing would change from the user perspective? Only the imports are more restricted, and no scikit-learn imports happen on module level anymore.

@SimonBlanke
Copy link
Owner

However, if we do not change pyproject.toml, I believe nothing would change from the user perspective? Only the imports are more restricted, and no scikit-learn imports happen on module level anymore.

yes, this will work fine.

Copy link
Owner

@SimonBlanke SimonBlanke left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Task: remove changes in pyproject.toml

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants