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, meaning 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 install from. 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.

No account and no token beyond your own GitHub and PyPI credentials. There is nothing to sign into for this.

The release refuses to start unless both channels would accept it right now, so a version number is never burned on a token that was going to fail. If one channel does fail after the other has accepted, finish it with release:resume, which publishes what is missing without bumping the version, and check the whole workspace with check:releases.

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. You edit it in your own splent_spl_<name>/ repository and publish it with one command.

splent login
splent spl:publish my_spl

This is the one thing in SPLENT that does go through the marketplace, and the reason it has a login at all.

you --(splent CLI, bearer token)--> MARKETPLACE --(one key)--> UVLHub

spl:publish sends the model to the marketplace, which relays it to UVLHub on its own key, mints or versions the DOI, verifies the published file byte for byte against what you sent, and answers with the DOI it recorded. Identical bytes it has already published get that same DOI back rather than a second one.

You never generate a UVLHub API key. The marketplace holds one for everybody, so there is no write_dataset scope to request, no UVLHUB_API_KEY to export, and nothing on uvlhub.io you need an account for. If you set that variable in an older workspace, nothing reads it any more.

The DOI that comes back is written into your model’s metadata.toml, and into each product with spl:pin. Publishing does not move any product onto the new version, and spl:publish names the ones still on the old one.

The reverse direction, spl:fetch, is not authenticated. It downloads models by DOI straight from UVLHub, which is how CI and fresh workspaces obtain the .uvl files with no account and no login.

See login for where the token is stored, and whoami for which credential is in use.

What deliberately does not exist

Missing on purpose	Why
Upload form / publish API for features	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.
An account to publish a feature	GitHub and PyPI already are the distribution and identity layer. `feature:release` is the only publish action for a feature, and there is nothing to sign into. The marketplace login exists for exactly one thing, publishing a variability model, because that is the one operation somebody has to hold a UVLHub key for.
A UVLHub key of your own	The marketplace holds one for everybody. Handing every developer a `write_dataset` key was handing out the exact credential the marketplace exists to replace.
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.