Publishing your feature

There is no upload. You release your feature on your own GitHub org, open one pull request to get listed, and the marketplace derives everything else from your released tag.

1. Make it a real SPLENT feature
2. Release it
3. Get listed
4. Publish your SPL’s model (if you maintain a line)
What deliberately does not exist

1. Make it a real SPLENT feature

The marketplace renders contracts, so your feature must have one — and contracts are generated, not written:

Follow the feature anatomy and naming conventions (splent_feature_*, src/ layout, contract in pyproject.toml).
Let feature:contract --write infer [tool.splent.contract] from your code. Set the preserved fields once — description, category, tags, and requires.features_manual for dependencies static analysis cannot see. See pyproject.toml for every field.

2. Release it

splent feature:release

feature:release regenerates the contract, bumps the version, creates a semver tag (vX.Y.Z) and publishes to GitHub (and PyPI, which production builds require). The tag is the publication: the marketplace always reads your pyproject.toml at the latest released tag, never from main — an unreleased feature is invisible, and reported as such by the indexer.

3. Get listed

Being indexed is a curated, one-line change — the Homebrew-tap model. Open a pull request against splent-io/splent_index adding your org or repo to registry.toml:

[registry]
orgs  = ["splent-io"]
repos = ["your-org/splent_feature_billing"]

Once merged, CI rebuilds index.json (on every push, every 6 hours, and on demand). The build runs marketplace:index, which validates at index time: it resolves your latest semver tag, parses the contract there, and skips (and reports) repos with no released tag or a broken contract. You never push data into the marketplace — the index pulls from you.

4. Publish your SPL’s model (if you maintain a line)

Product lines carry a UVL variability model, and the .uvl files are not tracked in git — UVLHub is their remote source of truth. After editing a model locally:

splent spl:publish my_spl

spl:publish uploads the model to UVLHub, mints or versions its DOI, and records it in the catalog’s metadata.toml — but only after downloading the published file back and verifying it byte-for-byte against your local copy. On any mismatch, nothing is recorded.

You need a UVLHub account and an API key with the write_dataset permission, generated at https://www.uvlhub.io/developer/api-keys:

export UVLHUB_API_KEY=<your-key>

The reverse direction is spl:fetch, which downloads models by DOI — it is how CI and fresh workspaces obtain the .uvl files.

What deliberately does not exist

Missing on purpose	Why
Upload form / publish API	The index is a regenerable cache over released tags. An upload channel would create a second source of truth that can drift from your repo — the exact failure mode SPLENT is designed against.
Marketplace accounts	GitHub and PyPI already are the distribution and identity layer. `feature:release` is the only publish action; there is nothing to sign into, and no credentials for the marketplace to leak.
Manual index edits	If the index is wrong, the fix is in a contract or a tag — regenerate and it is correct again. Editing `index.json` would only hide the real bug until the next rebuild.
Push-based listing	Curation by reviewed pull request keeps the registry auditable and the barrier honest: releasing well-formed, contracted features is the whole submission process.

Run check:contracts before releasing if your feature participates in an SPL — it verifies your contract and the UVL constraints tell the same dependency story.