Skip to content
Beskid Beskid

Beskid

Jump to a Beskid service

Beskid

Jump to a Beskid service

Packages

The registry stores a .bpk artifact at an immutable package name-and-version coordinate. Use beskid pckg for ordinary package commands. The equivalent grouped form is beskid dev package registry; this guide uses the concise form.

A package author needs a package name and a publisher API key with publish scope. A package consumer needs the package name and an exact active version.

  1. Configure credentials and recovery before a package mutation.
  2. Create, pack, inspect, and upload a package.
  3. Consume the exact package version through a project manifest and lockfile.
  4. In VS Code, use the Packages view for the focused project’s declared and locked dependencies.
sequenceDiagram
  accTitle: Package publication and consumption
  accDescr: A package author creates a record and uploads an artifact. A consumer requests a version and verifies the resolver result before accepting the lockfile.
  participant A as Author
  participant R as Registry
  participant C as Consumer
  A->>R: Create package record
  A->>R: Upload .bpk
  R-->>A: Immutable name and version
  C->>R: Request version
  alt requested active version exists
    R-->>C: Requested version
  else requested version is absent
    R-->>C: Fallback first active
  end
  C->>C: Materialize dependency
  C->>C: Update Project.lock
  C->>C: Inspect resolved_version

The package author first creates the package record. The author then packs and uploads one artifact. The registry assigns that artifact to an immutable name-and-version coordinate. A package consumer requests a version in the project manifest. The resolver can fall back to the first active version when the request is absent. Fetch materializes the selected artifact and writes Project.lock. The consumer then inspects resolved_version and stops all later work on a mismatch. A yanked version is not available for a new download.

The author can verify one immutable name-and-version coordinate and its checksum. The consumer has a reviewed Project.lock and a materialized leaf under obj/beskid/deps/src/<materialized-id>.

If identity, checksum, or generated documentation is wrong, do not upload the artifact. The resolver can fall back, which is an implementation limitation under reconciliation. Stop when the lockfile differs from the request. Use credentials and recovery for authentication failures, yanking, and key rotation.

Publish a package, consume a package, or use Packages in VS Code.