[FEATURE] Provisioner registry and install layer for Score (score-hub)

[ShantKhatri]

Detailed description

Installing a community provisioner today is done by copy-pasting a raw GitHub URL:

score-k8s init --provisioners \
  https://raw.githubusercontent.com/score-spec/community-provisioners/refs/heads/main/dapr-pubsub/score-k8s/10-redis-dapr-pubsub.provisioners.yaml

That's 140+ characters, it's platform-specific, there's no checksum, nothing is pinned, and there's no record of what was installed. As community-provisioners grows this gets worse.

I'd like to discuss adding a proper install layer so developers can do:

score-hub install dapr-pubsub --variant redis

Context

Provisioners are how platform engineers wire resources to Score workloads. Every developer hits the install step whenever they onboard to a new resource type. The raw URL workflow is the first impression and it's rough.

Specific problems right now:

• No discovery: you have to already know the URL or go searching on GitHub
• No variant selection: dapr-pubsub has a rabbitmq variant and a redis variant, you pick by editing the URL
• No integrity check: the URL can silently serve different content at different times
• No lock file: nothing records what was installed, at what commit, or with what checksum, so environments aren't reproducible
• No way to mix official and internal provisioners in the same workflow

I built a POC called score-hub-cli (https://github.com/ShantKhatri/score-hub-cli) to explore what this could look like.

Possible implementation

The core primitives any solution would need:

An index - a structured YAML describing available provisioners, variants, platforms, and checksums. Something like:

- name: dapr-pubsub
  category: messaging
  variants:
    - id: redis
      platforms:
        k8s:
          path: dapr-pubsub/score-k8s/10-redis-dapr-pubsub.provisioners.yaml
          checksum: "sha256:bd80a6bc..."
        compose:
          path: dapr-pubsub/score-compose/10-redis-dapr-pubsub.provisioners.yaml
          checksum: "sha256:8434fbfd..."

A lock file - .score-hub.lock committed to source control, pinning every installed provisioner to a specific version, commit, and checksum. Same idea as a go.sum or package-lock.json.

Platform auto-detection - inspect .score-k8s/ or .score-compose/ directories to figure out which Score platform is active so you don't have to specify it every time.

Additional information

POC: https://github.com/ShantKhatri/score-hub-cli (Go, Resolver interface abstraction, GitHub-backed index)

The POC currently indexes 11 provisioners from community-provisioners across 28 variants (messaging, networking, storage, compute, LLM, configuration).

[ShantKhatri]

Hi @mathieu-benoit, the registry scope question is the main design decision that shapes everything else. Single-source (official community-provisioners only) means integrating into the Score CLIs makes sense. User-defined registries means there's shared config state that needs to live outside any single CLI.

Once that's clear, a few other things to work through are index ownership and third-party submission flow under score-spec, trust model beyond checksum verification, whether provisioner contracts are a prerequisite for registry listing or independent, and compatibility with specific Score spec versions.