skore.show_activity() a simple helper function to get users started

[GaelVaroquaux]

Is your feature request related to a problem? Please describe.

As mentioned in #1001 , we need to bridge the skore notions of store, activity feed, UI, to the way many data scientists currently work: interactive work in vscode and jupyter notebooks.

Getting immediate benefits of skore requires setting up a project, and opening a web browser. This is a central sequence of operation that we can expect users to be doing over and over.

It requires knowing (and remembering) that "skore launch project_name" must be run.

It requires to open a shell, and run the corresponding command, in the right python environment. Shell commands and Python environment mess is a place where it is easy to loose users.

Describe the solution you'd like

I would like a small function to do all this for me.

>>> import skore
>>> p = skore.show_activity()   # Here a browser is opened with the activity feed
>>> p.put(reporter)

Short term, it helps getting people started (eg by inserting it in every one of our example) and stupid mistakes. In the long term, we can insert more cleverness (like detecting that we are on a compute cluster and not actually starting a web browser there :) , avoid starting multiple browsers for the same project on the same computer, potentially closing the server at the exit of the Python executable where it was started, to avoid pollution of servers).

Unlike skore.create, skore.show_activity should by default:

1. Create the project with a default name
2. Not complain if the project already exists, but not overwrite it

[glemaitre]

Unlike skore.create, skore.show_activity should by default:

• Create the project with a default name
• Not complain if the project already exists, but not overwrite it

To me it seems like exposing the current __quickstart private function that is already available via the CLI. But it should be fixed as spotted in #995

[glemaitre]

Let's start a discussion about the scope of functionality here.

@MarieS-WiMLDS provides her views on the feature in #1194 (review)

I disagree with @glemaitre on the fact that the creation function should also open the UI. these are two different things, we should have a python func to launch UI indeed, but it would be dedicated to this and only this.

@GaelVaroquaux mentioned his wishes as:

Unlike skore.create, skore.show_activity should by default:

• Create the project with a default name
• Not complain if the project already exists, but not overwrite it

On this I would wish the same feature as @GaelVaroquaux. #1157 added a parameter to open to be able to open the dashboard/feed/ui at the execution of the function at the same time than creating the project. As a minimum example:

# explicitely passing create, overwrite, and server but there are the actual
# default values
project = skore.open("project.skore", create=True, overwrite=False, serve=True)

project.put(...)  # live interaction in the started server above

In addition to the incentive that @GaelVaroquaux mentioned, I foresee 2 comparable UX that I pretty much like:

• dask dashboard: starting the client that main expectation is to start the scheduler will also start the dashboard server such that you can see what the scheduler will do. They do not provide a separate command just to launch the dashboard.
• The experience in a VS Code, is to launch an interactive window on the side when executing the first cell, and not just start an ipykernel and execute the code in background.

The fact that I'm expecting skore to provide live feedback makes that we should make it the de facto behavior for developer to get the server and browser or tabs in IDE started. Requiring an extra function will not indicate at a first glance that a live feedback is happening. For instance, looking at the demo of TensorBoard here, the fact that I see a call to %tensorboard (it could a function call as well), make me think that the board is actually only showing activity or a compilation of results that happen after computation. And for me, it is where I would like this additional UX due to the live nature of potential feature.

NB: #1194 makes it easier to deal with the Project class if you really want to. So it is a bit similar to matplotlib and for instance matplotlib.pyplot.figure vs. matplotlib.Figure. As a user, I'll probably go with the factory plt.figure(...). If I really want full control (but I usually never need to), I can use matplotlib.Figure(...). I'm not sure that I can convince people with the UX of matplotlib thought :)

[MarieS-WiMLDS]

Update in my thoughts: given that now we are starting a project with a init directly and not a function, we can add a new function which main purpose is to launch an UI, and which may (not convinced yet, but not so opposed) happen to create a project on the way if it doesn't exist yet.
I would still find it weird to do something like skore.Project(path = "project_name", launch-ui = True), as it's both creating a project and starting a web server at the same time. Totally not the same world.

[glemaitre]

I would still find it weird to do something like skore.Project(path = "project_name", launch-ui = True)

@MarieS-WiMLDS I completely agree. It is not what I proposed. Basically, we associate a server to a project by setting project._server_info but it is a completely private attribute, not user facing. Basically, a completely public API would be:

server_info = launch_server()
skore.Project(path="project_name", server-ui=server_info)

But I really think that a user should not have to deal with this low level stuff. Those actions should happen under the hood (and it is the purpose of the function). In pseudo code, it would be

def open(path="project_name", server=True):
    project = skore.Project(path=path)
    if serve:
        server_info = launch_server(project=project)
        project._server_info = server_info

[MarieS-WiMLDS]

This seems great! I'm setting this issue as ready since it seems that we are reaching a cool solution!

[MarieS-WiMLDS]

🎉