Create a project submodule for project related utilities

[glemaitre]

Is there a rationale for not creating a project submodule. I find it a bit weird to have a cross_validate next to load that have nothing in common.

I would find it natural that cross_validate also leave in skore.model_selection if the goal is to mimic or minimize changes compare to the current scikit-learn code.

For the project submodule, it would allow to gather utilities such as create, clean, launch that would expose a Python API associated with the CLI commands. It is much more natural to have a Python API only in notebooks as mentioned in #716. But IMO, the location of these tools matter.

[thomass-dev]

Is there a rationale for not creating a project submodule. I find it a bit weird to have a cross_validate next to load that have nothing in common.

No, just an arbitrary choice and just a taste. I, too, prefer to store things in their dedicated directories.
Currently, the wrapper of the cross_validate function was moved to sklearn/. We think to split the module into several, it will probably be moved to sklearn/cross_validation/.

I vote +1 to move project.py in project/.

I would find it natural that cross_validate also leave in skore.model_selection if the goal is to mimic or minimize changes compare to the current scikit-learn code.

For that part, i'm not totally agree. We should keep the layout sklearn/ if we want to wrap several third libraries.
But we can move the module in a dedicated sub-directory model_selection.

What's your feeling about putting the cross_validate wrapper in skore/sklearn/model_selection @glemaitre @MarieS-WiMLDS?

For the project submodule, it would allow to gather utilities such as create, clean, launch that would expose a Python API associated with the CLI commands. It is much more natural to have a Python API only in notebooks as mentioned in #716. But IMO, the location of these tools matter.

I should not prefer to mix CLI with other codes. But, if the question is to define the newly created project management functions in project/, and to use it in the CLI, i totally agree.

[MarieSacksick]

What's your feeling about putting the cross_validate wrapper in skore/sklearn/model_selection ?

We do not plan to duplicate and wrap all scikit-learn functions. Therefore, it doesn't make sense to have a full mapping of the architecture of functions. We would end up with a tree where the leaves may have only one function. Moreover, as a user, I find it very troublesome when I have to know and remember the full path to a function, I prefer to have the shortest as possible (as a developer, like you, I prefer when my code is clean and well organized ;) ).
It was also the opinion of Gaël, who advised to start with all functions at the root of the library, and we might change later to build a tree. It's more difficult to go the other way around according to him if we notice later that our tree doesn't make sense given the new features developed.