Separate package source, registry protocol, and runtime fields for better flexibility

[beshkenadze]

Pre-submission Checklist

• I have verified this would not be more appropriate as a feature request in a specific repository
• I have searched existing discussions to avoid duplicates

Your Idea

Idea

The current schema defines a single field registryType (e.g., npm, pypi, oci, nuget, mcpb) to describe how a package is retrieved.
However, this conflates multiple concepts:

• Where the package is hosted (e.g., GitHub, GitLab, private registry)
• How it is fetched (npm, PyPI, OCI, etc.)
• How it is executed (npx, bunx, deno, uvx, docker, etc.)

This makes it difficult to describe hybrid scenarios, such as a package distributed through an npm-compatible registry hosted on GitHub and executed via Bun or Deno.

---

Proposal

Split the existing registryType into distinct fields to improve clarity and future extensibility:

{
  "sourceType": "github",       // where it is hosted
  "registryProtocol": "npm",    // how it is fetched
  "runtimeHint": "bunx",        // how it is executed
  "registryBaseUrl": "https://npm.pkg.github.com"
}

This preserves backward compatibility while allowing richer modeling for cross-registry and multi-runtime use cases.

---

Benefits

• Clearer separation of responsibilities
• Easier support for new registries and runtimes
• Reduced need to expand hardcoded enums
• More accurate metadata for SDKs and automation tools

Scope

• Protocol Specification
• SDK Features
• Documentation
• Developer Experience
• Other

[tadasant]

However, this conflates multiple concepts:
Where the package is hosted (e.g., GitHub, GitLab, private registry)
How it is fetched (npm, PyPI, OCI, etc.)
How it is executed (npx, bunx, deno, uvx, docker, etc.)

The intent behind the registryType field is to communicate:

• Where the package is located (e.g. if registryType=pypi, you could use a PyPi client to fetch it in accordance with whatever API schemas PyPi exposes)
• What you'll get when you fetch it. So in the registryType=pypi case, you know you're getting a python package (that you can go on to choose your favorite runtime for)

It's certainly not the How it is executed (npx, bunx, deno, uvx, docker, etc.) part: we have runtimeHint for that.

a package distributed through an npm-compatible registry hosted on GitHub and executed via Bun or Deno.

Wouldn't this work for you as-is with the current modeling?

{
  "registryType": "npm",
  "registryBaseUrl": "https://npm.pkg.github.com",
  "runtimeHint": "bunx"
}

Let me know if I'm misunderstanding.