I would support this as it seems like it could clear up a lot of confusion. Do you believe there are any people directly trying to use the functions that would be made private?

Since #14939 is merged, we seem to be deprecating them already for 0.22. This now seems like an easy one for some of the upcoming sprints. Although if we want it done before the end of october, we should do it ourselves maybe.

Below is the list of the folders whose files need to be preceded by an underscore. The procedure is pretty straightforward:

• rename file.py into _file.py and create a new file.py with a similar content that raises a deprecation warning (like neural_network/rbm.py)
• update __init__.py
• update test parametrization of sklearn/tests/test_import_deprecations.py

Folders

• compose -- no need \o/
• cluster
• covariance
• cross_decomposition
• datasets (MNT Make modules private in sklearn.datasets #15307)
• decomposition
• ensemble
• experimental -- irrelevant
• externals -- no need
• feature_extraction (MNT Make modules private in feature_extraction #15321)
• gaussian_process ([MRG] MNT Make modules private in guassian_process #15320)
• impute -- no need
• inspection ([MRG] MNT Make modules private in inspection #15334)
• linear_model ([MRG] MNT Make modules private in linear_model #15324)
• manifold ([MRG] Make modules private in manifold #15318)
• metrics ([MRG] Make files private for sklearn.metrics and sklearn.metrics.cluster #15306)
• metrics/cluster ([MRG] Make files private for sklearn.metrics and sklearn.metrics.cluster #15306)
• mixture
• model_selection -- no need
• neighbors ([MRG] MNT Make modules private in neighbors #15322)
• neural_network -- done in MAINT Deprecate any import that is not from sklearn.neural_net… #14939
• preprocessing ([MRG] MNT Make modules private in preprocessing #15323)
• semi_supervised ([MRG] Make modules private in semi_supervised #15317)
• svm
• tree
• utils -- irrelevant since addressed by Public vs. private utils again #6616 (comment)

(Note that this only addresses the folders. Files like sklearn/pipeline.py may still contain non-deprecated things.)

ping @thomasjpfan @glemaitre @adrinjalali let's pick one each and review each-other? this should go relatively fast

I'll pick cluster

I'm taking the tree and ensemble, since they're interrelated.

I'll take preprocessing and inspection at first

pretty sure folks have not been using git move correctly. Try doing a single commit that does the move and commit that, before adding anything else. Your PRs don't show files as moved, which means that something went wrong.

I did move, as you see in this commit df7f54d but once you create a file with the same name, github gets confused.

I'm working on mixture and svm

Working on covariance

working on cross_decomposition

working on metrics and metrics/cluster

I'll work on datasets

Working on gaussian_process

Working on feature_extraction

Working on inspection

Working on preprocessing

Working on linear_models

@thomasjpfan From the list, I only did not review the PR for the decomposition. I did not open a PR because you seem to have work on it. Could you open a PR?

ping @NicolasHug @thomasjpfan what about sklearn.feature_selection?

Is #15367 a blocker?

Working on feature_selection

what about sklearn.feature_selection?

Thanks I missed this one

Is #15367 a blocker?

Yes but it's tracked by another issue

I had a ton of private datasets, such as names, text and geographical data. I used to use the following utils to download and manage these:

from sklearn.datasets.base import (get_data_home, RemoteFileMetadata, _fetch_remote)

What's the recommended approach now?

you can import from sklearn.datasets._base import ...

However, now you are aware that _base will be private and you might have to change your code at a new scikit-learn release since we might not provide backward-compatible code.

This said, be aware that we are going to define a developer API which will define some backward support for these types of utilities used in third-party.