Packages

Packages

A Zinc package is an arbitrary self-contained software directory described by zinc.pkg.yaml.

Zinc stores only the package root in Limbo:

packages(package, root)

The manifest remains the navigable source of truth. Package internals stay in the package.

Manifest

name: openai-responses
version: "0.2.0"
about: OpenAI Responses-shaped model adapter package.

source:
  git: https://github.com/darkhorseprojects/darkhorseprojects-packages.git
  ref: main
  path: openai-responses

adapter: adapters/responses.py

shapes:
  short_answer: shapes/short-answer.circuitry.yaml

config:
  models: config/zinc.models.yaml

setup:
  linux: scripts/setup
check:
  linux: scripts/check
remove:
  linux: scripts/remove

References

References are manifest paths:

openai-responses.adapter
openai-responses.config.models
openai-responses.shapes.short_answer

shape: and model adapter: decide how the resolved file is used. Dot and slash navigation both walk the package manifest lazily.

Package boundary

Packages own:

adapters
tools
providers
shell behavior
OS behavior
setup/check/remove hooks
package config interpretation
package request/result shape

Zinc owns:

package root registration
manifest walking
config loading
exact request byte routing
choice lookup
fragment storage
assembly

A package request can be YAML, JSON, argv, a file path, or another byte format. That is the package contract, not a Zinc core schema.

Releases

Package repositories can contain many independently versioned packages. Tags should be package-scoped:

<package-name>-v<package-version>

Example:

openai-responses-v0.2.0

A release should validate that the tag package and version match zinc.pkg.yaml, run package checks, and attach a package archive plus checksum.

Soft dependencies

soft_dependencies names Zinc packages. They are resolved when referenced by package behavior or manifest paths.