chore: Hide view functions from project

[MarieS-WiMLDS]

Will actually be closed by #1052

We have functions about views in project which are documented & public, while we offer no specific feature related to a view. So far, it's something we want to deal with internally.
Suggesting this solution, but not sure it's the best since the view functions still appear in the autocomplete. Also, there is still the "view_repository" as one of the parameters of Project while it would be best to be hidden.

[github-actions]

pytest coverage report

File	Stmts	Miss	Cover	Missing
src/skore
__init__.py	18	0	100%
__main__.py	8	1	1	80%
exceptions.py	4	0	100%
src/skore/cli
__init__.py	8	0	100%
cli.py	32	0	100%
launch_dashboard.py	22	12	0	42%
quickstart_command.py	12	2	0	83%
src/skore/item
__init__.py	21	0	100%
cross_validation_item.py	127	10	2	92%
item.py	41	13	0	68%
item_repository.py	42	2	1	93%
media_item.py	70	4	1	94%
numpy_array_item.py	25	1	1	93%
pandas_dataframe_item.py	34	1	1	95%
pandas_series_item.py	34	1	1	95%
polars_dataframe_item.py	32	1	1	94%
polars_series_item.py	27	1	1	94%
primitive_item.py	27	2	1	92%
sklearn_base_estimator_item.py	33	1	1	95%
skrub_table_report_item.py	10	1	1	86%
src/skore/persistence
__init__.py	0	0	100%
abstract_storage.py	22	1	0	95%
disk_cache_storage.py	33	1	1	95%
in_memory_storage.py	20	0	100%
src/skore/project
__init__.py	4	0	100%
create.py	50	8	0	88%
load.py	23	3	0	89%
project.py	62	4	4	91%
src/skore/sklearn
__init__.py	3	0	100%
find_ml_task.py	19	2	3	85%
types.py	2	0	100%
src/skore/sklearn/cross_validation
__init__.py	2	0	100%
cross_validation_helpers.py	41	4	1	89%
cross_validation_reporter.py	37	1	1	95%
src/skore/sklearn/cross_validation/plots
__init__.py	0	0	100%
compare_scores_plot.py	29	1	2	92%
timing_normalized_plot.py	29	1	1	94%
timing_plot.py	29	1	1	94%
src/skore/sklearn/train_test_split
__init__.py	0	0	100%
train_test_split.py	34	2	1	94%
src/skore/sklearn/train_test_split/warning
__init__.py	8	0	100%
high_class_imbalance_too_few_examples_warning.py	17	3	2	78%
high_class_imbalance_warning.py	18	2	1	88%
random_state_unset_warning.py	11	1	1	87%
shuffle_true_warning.py	9	0	1	91%
stratify_is_set_warning.py	11	1	1	87%
time_based_column_warning.py	22	1	2	89%
train_test_split_warning.py	5	1	0	80%
src/skore/ui
__init__.py	0	0	100%
app.py	25	5	2	71%
dependencies.py	7	1	0	86%
project_routes.py	50	0	100%
src/skore/utils
__init__.py	0	0	100%
_show_versions.py	29	0	100%
src/skore/view
__init__.py	0	0	100%
view.py	5	0	100%
view_repository.py	16	2	1	83%
TOTAL	1299	99	91%

Tests	Skipped	Failures	Errors	Time
194	0 💤	0 ❌	0 🔥	46.174s ⏱️

[thomass-dev]

We have functions about views in project which are documented & public, while we offer no specific feature related to a view. So far, it's something we want to deal with internally.

Managing a view from the developer interface was in the original design. We don't want to do this anymore? (ping @tuscland )

[tuscland]

I agree that it is weird to have those repositories exposed. This is private stuff.

However, being able to build views programmatically can be useful. I would like to discuss with Marie offline about her intent in creating this issue. Maybe it is part of a larger project that I am not aware of at the moment.

[thomass-dev]

I've re-drafted the PR as long as there is an open discussion.

[MarieS-WiMLDS]

My intent is to have a library that is as simple as possible for the user. When they see a function, it really provides value to them, it helps them for a given use case they have appart from skore.
It will be useful to create repositories programmatically when the user can do something with their views. Today, it helps to visualise, but that's it, there is no sharing nor export. Therefore it's useful only for them: it's not something that will be done in high amounts, hence it seems to me that there is no need to create it automatically.

[tuscland]

@thomass-dev as discussed with Marie, it is a good decision to reduce the public API space and relegate View to private scope.

[glemaitre]

So if I follow well enough, this PR is superseded by #1052 and do not need any review and will be closed by #1052?

[MarieS-WiMLDS]

No because #1052 is about the items, while this is about the views.
However it is the same purpose behind indeed, we want to simplify the API and only ask the user to master new vocab only if it brings real value to them.

[glemaitre]

OK I see, I got confused because of the related issue (#1045 (comment)) where it is also mentioned that views should become private.

It would really help to have a proper description in PR summary.

[MarieS-WiMLDS]

ah, indeed, the TODO was enriched!
Ok so you're right, it will be tackled in #1052!
I'd rather keep this PR open until it's really done though.

[glemaitre]

Yes, it is just that we can add closes #... in the summary of the PR to close it at merge.