refactor!: Add new commands to manage HUB API keys

[thomass-dev]

Caution

Circular import: skore -> skore-cli -> skore.

IMO, we should sync the merge in the afternoon, and accept CLI to be red for a moment.
Should be merged before the release of probabl-ai/skore#3255.
Must be used with probabl-ai/skore#3255.

---

Part of probabl-ai/skore#3240.

skore hub api-key generate [--host=<host>] --workspace=<workspace>
skore hub api-key revoke [--host=<host>] --workspace=<workspace>
skore hub api-key list

feat: Add new commands to manage HUB API keys
feat: Move HUB API key generation to its own command
feat: Implement login directly in the CLI

Harness launch no longer injects SKORE_HUB_API_KEY into the agent process (or anything it spawns). The skore package already loads that key from the credential registry, so skore.login() is not needed for agent-run scripts.

Launch still copies SKORE_HUB_URI from .skore when it is not already set, so a non-default hub still reaches subprocesses.

Harness config writers still embed the workspace API key (Claude token, Cursor MCP bearer, etc.). That authenticates the harness itself, not the skore SDK.

[rouk1]

Thanks !

Appart from my comment about workspace flag not being mandatory it looks good to me.

It is a bit strange that delete does nothing if host is not passed.
The docs states its not mandatory but I think it is.

skore hub api-key delete --help

 skore  · ML reporting & agent skills

 Usage: skore hub api-key delete [OPTIONS]

 Delete a stored Hub API key for a workspace.

╭─ Options ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│    --host       TEXT  Hub host URL.                                                                                                                                                                                           │
│ *  --workspace  TEXT  Hub workspace whose key to delete. [required]                                                                                                                                                           │
│    --help             Show this message and exit.                                                                                                                                                                             │
╰───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

skore-cli on  skore-hub-api-key is 📦 v0.4.0 via 🐍 v3.14.0 (skore-cli) via 🧚 v0.41.4
✦ ❯ skore hub api-key delete --workspace matthieu

skore-cli on  skore-hub-api-key is 📦 v0.4.0 via 🐍 v3.14.0 (skore-cli) via 🧚 v0.41.4
✦ ❯ skore hub api-key list
            Hub API keys
┏━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━┓
┃ host                  ┃ workspace ┃
┡━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━┩
│ http://localhost:8000 │ matthieu  │
└───────────────────────┴───────────┘

---

[glemaitre]

I tested the feature in windows and I have the following question:

Should we expose the --expires flag to be aligned with the hub in generate command

What are the permissions that we created with the key. Do we need to think about exposing those or we actually don't care?

I got a bit confused by UX related to the generate and delete: in short, generate will generate a key on the hub and add it in the keyring locally. If you generate a second key for the same workspace and host then, you have a second key on the hub but the list will show you a single one locally because you are only interesting about the tuple (host, workspace) and I imagine that you are only storing the last key generated. Somehow, I would expect to have an exact alignment with a tuple (key-name, workspace, host) and delete will delete one of them. I was thinking then to system like GitHub and just realise that they don't have a generate command but only a way to generate the key and add in the hub. So here we have a different UX which I like but I'm wondering if a complete alignment would make it less confusing.

[rouk1]

Do we need to think about exposing those or we actually don't care?

Yes but imo only if we spawn some kind of tui in which you may select the permission. If only using the cli then we should just add project permissions (no invitations).

About adding multiple keys. I suggest that we raise an error if one tries to add a api key for an already known host/workspace couple.

In pseudo code:

def add_key(host, workspace):
    k = keyring.get(host, workspace)
    if k is not None:
        if api.authenticate(k):
            prompt("You already have a key for this env, would you like to delete it and create a new one ?")
            ...
        else:
            print("Key expired creating a new one")
            ...
    k = api.generate_key(host, workspace)
    keyring.set(host, workspace, k)

I think the add sub command is confusing it creates two way to manage keys in the keyring. Imo the path in which you copy paste is to complicated for users. If they already have an API key we may suggest them to use an env var rather than storing it to the keyring.

[glemaitre]

OK so I pushed the following change:

• add the --expires flag to generate to align with the hub
• add the --force flag to generate to allow overwriting an API key and only key one by hardware
• remove the add command to have a single way to create a key
• make sure that delete is also deleting the key from the hub workspace
• make that that we use the API key ID in order to disambiguate the key at removal time to not alter an API key from another device