Publish to the store

Publishing takes a package you authored and lists it on the LSD Store so others can find, acquire, and install it. Free and paid builds use the same immutable package/content boundary; paid content inherits its exact parent package licence.

The publishing flow#

1. Create a publisher account on the web store — this is the publisher namespace your package names in its manifest.
2. Build the canonical code submission as name-version.lsdpackage. It contains package code and metadata, never an examples or assets sidecar.
3. Upload a version from Creator Studio. The Store validates the archive and creates that exact coordinate as a draft review candidate.
4. Attach content if wanted. Upload zero or more .lsdcontent files while the code coordinate remains draft. Each pack is independently named and may be required with the package or optional.
5. Submit for review. This locks the exact code, content set, offer, and Store presentation. An operator can approve or reject the immutable candidate with feedback; only an approved candidate can become the public version.

Each upload is a new version; clients install only a version they acquired and whose exact digests and signature verify.

Package identity#

A Store package's manifest carries the publishing identity on top of the normal v1 fields:

{
    "_schema_version": 1,
    "name": "lsd-widgets",
    "version": "1.0.0",
    "publisher": "acme",
    "paid": false,
    "tool": "tool"
}

• publisher must equal the publisher slug owned by the signed-in account.
• paid must match the exact offer saved in Creator Studio.
• name and version must match the upload filename, submission metadata, package header, manifest, and Creator Studio draft.

Optional content packs#

A package version may publish no content at all. When it does, every .lsdcontent pack contains exactly one content/<id>/lsd_content.json, an optional 640x360 preview.png, and data under payload/. Categories are template, sample, or learning. Project entries are complete project templates or tutorials; documentation entries are inert data. Python, bytecode, scripts, executables, links, traversal, and malformed project documents are rejected.

required: true means Hub installs the pack in the same transaction as the package and all of its dependencies. Optional packs can be installed or removed later. After review submission the set is locked; publish a new package version to add, remove, or replace content.

Signing & trust#

Every published package is countersigned. Clients verify the signature against the pinned Store key before loading a package, so a tampered or forged build is rejected. The key document is available at /catalog/v1/signing-key; pin it deliberately rather than trusting a key first seen during an install.

Related#

Learn — Acquire & install · The Package Manager

API — lsd_package.json · PackageManager

Examples — A complete package