Publishing & API

1. Point ez at this registry

ez config registry https://packages.ez-lang.site

2. Create an account

ez login

Prompts for a username, email and password, then stores the API token in ~/.ez/credentials.json. The first account created on a fresh registry becomes its administrator.

3. Describe your package

A package.ez in the project root:

{
  "name": "http-client",
  "version": "1.2.0",
  "description": "A small HTTP client",
  "main": "main.ez",
  "license": "MIT",
  "keywords": ["http", "network"],
  "dependencies": {
    "json": "^1.0.0",
    "log":  ">=2.1.0 <3.0.0"
  }
}

4. Publish

ez publish

A published version is immutable. To correct a mistake, publish a new version; to stop new installs picking a bad one, ez yank <pkg>@<version> — that hides it from resolution without breaking anyone who already depends on it.

Version ranges

Range	Matches
`1.2.3`	exactly that version
`^1.2.3`	≥1.2.3 and <2.0.0
`~1.2.3`	≥1.2.3 and <1.3.0
`>=1.2.0 <2.0.0`	an explicit range
`1.2.x`	any patch of 1.2
`*`	the newest stable version

Prereleases (2.0.0-beta.1) are never selected by a range; ask for one exactly to get it.

HTTP API

Endpoint	Purpose
`GET /api/v1/packages?q=`	search
`GET /api/v1/packages/:name`	metadata and every version
`GET /api/v1/packages/:name/:range`	resolve one range
`GET /api/v1/packages/:name/:version/download`	tarball
`POST /api/v1/resolve`	full install plan for a dependency set
`POST /api/v1/publish`	publish (multipart, bearer token)
`POST /api/v1/packages/:n/:v/yank`	yank / unyank

Resolution happens server-side: send what you want, receive a flat, ordered plan with tarball URLs and SHA-256 checksums.

curl -X POST https://packages.ez-lang.site/api/v1/resolve \
  -H 'Content-Type: application/json' \
  -d '{"dependencies":{"http-client":"^1.0.0"}}'