PlatformIO Core

ID

platformio-core

Home page

https://platformio.org

Platforms

🐧 Linux · 🍎 macOS · 🪟 Windows

Operations

installed · upgrade_all

purl types

pkg:platformio-core

CLI name

pio

Issues and PRs

📦 manager: platformio-core

Source

meta_package_manager/managers/platformio_core.toml

PlatformIO Core’s package manager (https://platformio.org), wrapped for the platforms, tools and libraries it installs machine-wide.

A package is whatever pio pkg list --global reports, which spans three kinds at once: development platforms, the toolchains they build with, and libraries. The listing groups them under a heading per kind and prints one entry per line, so the kind is context rather than part of the id.

Parsing notes, verified against PlatformIO Core 6.1.19 on macOS:

  • Global scope is a flag on every command. Without --global the whole pkg surface answers for the project in the working directory, which is the haxelib hazard. list, install, uninstall and update all take it.

  • No outdated, and this is the reason: pio pkg outdated is the one command in the family that has no --global, taking only --project-dir and --environment. Its single staleness read therefore answers for a working tree rather than for the host, which is the cabal outdated shape.

  • No install and no remove, because a package’s kind is a flag. pio pkg install and pio pkg uninstall take the specification as the value of --library, --platform or --tool, never as a positional: both answer Error: Got unexpected extra argument when handed a bare name. An id alone cannot drive either verb, and install in particular cannot infer a kind for a package it has never seen. The listing does carry the kind in its headings, so a Python class could look up what to remove; a definition cannot, one operation being one command.

  • The ids are a pair. The listing prints the short name, ArduinoJson, while install and search use the owner-qualified bblanchon/ArduinoJson that the entry shows only inside its (required: ...) suffix. Removal accepts the short name, so the id yielded here is the one that would round-trip out of the inventory.

Todo

Declaring search would need a class: its records span three lines. It is worth the upgrade, because those records carry a server-set publication date (“Published on Mon Mar 2 17:23:45 2026”), which is what qualifies a manager for the per-package release_date() probe under --cooldown instead of the ❌ row this definition earns. Doing that would also unlock remove, the kind lookup being the same class-only capability.

What mpm adds to platformio-core

mpm reaches across every manager at once, not platformio-core alone: mpm installed and mpm outdated cover platformio-core alongside every other manager you run in one table, mpm upgrade --all updates them together, and mpm sbom exports the whole machine as one bill of materials.

Every mpm command also gains --dry-run and --plan previews, cross-scheme version comparison and purl identifiers. See manager augmentations for how each one is built.

Operations

Operation

Supported

installed

✓

outdated

orphans

search

install

upgrade

upgrade_all

✓

remove

sync

cleanup

doctor

Selecting and configuring platformio-core

Deselect platformio-core for a single run with --no-platformio-core, or persist the choice in your configuration:

[mpm]
platformio-core = false

Keep it enabled but tune how mpm drives it with a per-manager override:

[mpm.managers.platformio-core]
timeout = 900

mpm config-template platformio-core prints every overridable attribute as a ready-to-paste block.

Recipes

A few jobs you would otherwise script around platformio-core, one mpm command each:

  • Snapshot and clone a machine: mpm --platformio-core dump platformio-core.toml, then mpm restore platformio-core.toml on the next one.

  • Export a compliance SBOM: mpm --platformio-core sbom (CycloneDX by default, --spdx for SPDX).

Privilege escalation

mpm runs this manager as the current user and never prepends sudo by default. Flip the policy for its privileged operations with --sudo or the per-manager sudo override.

None of its operations needs root.

See privilege escalation for the full policy.

Cooldown

State of PlatformIO Core’s release-age gating, from the cooldown support table:

Status: ❌ None (registry dates a release, but no declared operation reads them)

A cooldown only pays off where a compromised release can be withdrawn while the clock runs, and can only be emulated where the registry dates its releases. From the retraction table:

  • Registry: PlatformIO Registry

  • Retraction: Unpublish: pio pkg unpublish withdraws a pushed package from the registry, the one verb in the family that acts on what was published rather than on what is installed

  • Publish date: ✅ pio pkg search prints a per-package Published on date, server-set, though no declared operation reads it yet

With --cooldown set, mpm skips this manager’s install and upgrade operations rather than run them unguarded (fail-closed); --cooldown best-effort opts back in.

Version probe

The version is probed by running:

$ pio --version
PlatformIO Core, version 6.1.19

and extracted with:

r"PlatformIO Core,\s+version\s+(?P<version>\S+)"

Reference traces

Raw native outputs captured in the bundled definition: the reference mpm’s parsers were written against. If you know PlatformIO Core well and a transcript below looks wrong, or a newer release changed its output format, report it.

$ pio pkg list --global
Tools
└── tool-scons @ 4.41101.0 (required: platformio/tool-scons)

Libraries
└── ArduinoJson @ 7.4.3 (required: bblanchon/ArduinoJson)

Feed any of these through mpm and the raw output becomes one uniform table, the same shape for every manager: filter it, project columns, or export it (mpm --platformio-core installed --output json, or csv, toml, yaml), each package carrying a purl and a version comparable across managers.

Changelog

  • 8.0.0.dev0 (unreleased)

    • Add PlatformIO Core package manager, listing and upgrading the platforms, tools and libraries it installs machine-wide.