Skip to content
Russet

Compatibility with AutoPkg

Russet targets compatibility with AutoPkg 3.0.0, specifically AutoPkg commit c36e58f, and with Munki 7.2.0.5787 for the metadata that it generates. This page explains what that compatibility covers, what Russet intentionally doesn’t support, and how the project tests it.

What stays the same

Section titled “What stays the same”

Russet keeps the parts of AutoPkg that your recipes, preferences, and schedules depend on:

  • The command: the russet command accepts the same verbs and options as the autopkg command. Only the command name differs, so scripts and scheduled jobs that run autopkg need to run russet instead.
  • Recipes: Russet reads property list recipes, with the .recipe or .recipe.plist extension, and YAML recipes, with the .recipe.yaml extension. Recipes keep the same Identifier, ParentRecipe, MinimumVersion, Input, and Process keys.
  • Overrides and trust information: recipe overrides and their ParentRecipeTrustInfo keep the same format and verification rules.
  • Processors: built-in processors keep their names, input variables, output variables, and default values.
  • Preferences: Russet reads the same preference keys and formats, but from its own location, such as the com.github.russet domain on macOS. To copy Python AutoPkg’s preferences, run russet migrate. Russet never changes Python AutoPkg’s preferences. For details, see Preferences.
  • Results: receipts, report property lists, and the run results file keep their formats.

Russet’s installation is separate from Python AutoPkg’s. It installs in /opt/russet, links /usr/local/bin/russet, and runs its helper services under its own launchd jobs and sockets, so you can install both tools on the same Mac.

What Russet doesn’t support

Section titled “What Russet doesn’t support”

Russet intentionally doesn’t run Python, so it doesn’t support features that need a Python interpreter:

  • Custom processors: a recipe repository can supply its own processors as Python files. Russet doesn’t run them. If a recipe uses a processor that Russet doesn’t implement, Russet reports Custom or unknown processor 'NAME' is not supported and runs none of the recipes that you requested.
  • Munki repository plug-ins: Russet supports only Munki’s FileRepo backend. It rejects other values of MUNKI_REPO_PLUGIN and Munki repository URLs other than file:// URLs.
  • Python Munki libraries: Russet rejects force_munki_repo_lib and generates Munki metadata natively.

Russet implements some processors that recipe repositories commonly supply, such as MozillaURLProvider and MakeCatalogsProcessor. When a recipe uses one of those names, Russet runs its native implementation and never runs the repository’s Python file. For the list, see Processors.

Intentional differences

Section titled “Intentional differences”

A few behaviors differ from Python AutoPkg by design:

  • Terminal output: in a terminal on macOS or Linux, russet run shows a live display of each recipe and its processors. Use --plain for AutoPkg’s output. Output that you pipe or redirect doesn’t change. For details, see Live display.
  • Failure details: the traceback field in a failure report contains a native backtrace instead of Python stack frames.
  • Munki options: Russet rejects unknown makepkginfo options and options that only change makepkginfo output, such as --version, with an explicit error.
  • Predicates: on Linux and Windows, StopProcessingIf supports a subset of the predicate syntax. For details, see Platform support.
  • Platform-specific operations: an operation that needs another platform’s tools fails with an error instead of running a partial substitute.
  • Trust location: Russet doesn’t trust an override inside a recipe repository. For details, see Recipe trust.

How the project tests compatibility

Section titled “How the project tests compatibility”

The Russet repository contains no Python. The tests that compare Russet with Python AutoPkg live in a separate repository, russet-compat. Its suites download Python AutoPkg at the target commit, build Russet from source, give both the same input, and compare their results, including final variables, failures, reports, generated metadata, file changes, and command arguments. They run each week, and you can also run them against any Russet branch or commit.

Some tests in the Russet repository compare Russet’s results with output that the project saved from Python AutoPkg. These tests cover areas such as predicates, Munki catalogs, YAML recipes, and run receipts. Other jobs package Russet on each platform and test installation, upgrades, rollback, and the helper services.

The project also ran all 228 recipes in the autopkg/recipes repository on GitHub-hosted macOS runners on October 7, 2026. The results were as follows:

  • 121 recipes completed.
  • 94 recipes used custom processors, so Russet rejected them before they ran.
  • 13 recipes failed. Most failed in Python AutoPkg too, because of retired downloads, invalid upstream disk images, or recipes that need more input.

Russet then added native versions of the processors that those 94 recipes use. A second run of the 94 recipes on the same day had no processor rejections: 81 exited successfully, 12 failed, and one timed out. For the records of both runs, see the evidence folder in the russet-compat repository.

Tests show compatibility for the cases that they cover. They don’t prove identical behavior for every possible recipe, so check your own recipes before you rely on Russet in production.

What’s next

Section titled “What’s next”