rattler_index

rattler_index creates or updates conda channel indexes by writing repodata.json, optional compressed repodata, and optional sharded repodata for packages stored on a local filesystem or in S3.

CLI Usage

Index a local channel:

rattler-index --config ./rattler-config.toml fs ./channel

Index an S3 channel:

rattler-index --config ./rattler-config.toml s3 s3://my-bucket/my-channel

The --config flag points at the same TOML configuration file used by pixi. It configures S3 credentials, concurrency, and per-channel index options under the [index-config] section.

When --config is omitted, rattler-index falls back to its built-in defaults (write-zst = true, write-shards = true, no advertised repodata revisions, from-index-json revision assignment, no channel metadata).

Per-channel index configuration

Index options live in [index-config] and follow the same shape as [repodata-config]: a flat default block with optional per-channel overrides keyed by URL or absolute path. The most specific entry wins; less-specific entries supply fallback values, and [index-config] itself is the final fallback.

# Defaults applied when no per-channel entry matches
[index-config]
write-zst = true
write-shards = true
repodata-revisions = ["v3"]
package-revision-assignment = "from-index-json"

# Per-host: applies to every channel under this bucket
[index-config."s3://my-bucket"]
base-url = "../packages/"

# Per-channel: most specific entry wins, then falls back to the host entry,
# then to [index-config]
[index-config."s3://my-bucket/staging"]
write-shards = false
package-revision-assignment = "latest"

[index-config."s3://my-bucket/staging".channel-relations]
base = "../conda-forge"

# Local directory keys are absolute paths
[index-config."/srv/conda/internal"]
base-url = "../packages/"

Matching rules:

• Keys are compared against the canonical channel target — the full URL for remote channels (s3://...) or the canonicalized absolute path for local channels.
• Match is on path-component boundaries: s3://my-bucket matches s3://my-bucket/staging but not s3://my-bucket-other/staging.
• All matching keys are layered onto [index-config] in shortest-to-longest order, so the most specific entry overrides earlier values field by field.

Supported fields

channel-relations.base and channel-relations.overrides follow CEP-42 channel relationship metadata and must not point to the same channel.

Common configurations

Advertise v3 repodata for all channels:

[index-config]
repodata-revisions = ["v3"]

Advertise v3 repodata and assign every package to the newest configured revision for one specific channel:

[index-config."s3://my-bucket/staging"]
repodata-revisions = ["v3"]
package-revision-assignment = "latest"

Declare CEP-42 channel relationships:

[index-config."s3://my-bucket/my-channel".channel-relations]
base = "../conda-forge"
overrides = "../fallback"

The generated repodata.json then contains the metadata under info, for example:

{
  "info": {
    "base_url": "../packages/",
    "repodata_revisions": [
      {
        "revision": 3,
        "n_packages": 42
      }
    ],
    "channel_relations": {
      "base": "../conda-forge",
      "overrides": "../fallback"
    }
  }
}

The same channel metadata is also written into the sharded repodata index when write-shards is enabled.