RFC: auto-discovering pup-* extensions

[jkirsteins]

I'd like to improve the way pup extensions are discovered, so that they can be delivered easily via brew etc. Feedback welcome.

Summary

Today, pup extensions are discovered through pup-managed installs and manifest.json files. I’d like to simplify this model and make extensions easier to use by auto-discovering executables named pup-*, while keeping a clear security boundary before extensions receive Datadog credentials.

The key idea: discovery should be automatic, but execution should require explicit enablement.

This would also improve distribution through package managers such as Homebrew. A Homebrew formula can install an executable like pup-foo onto PATH, but it cannot reliably auto-register that extension with pup during post_install on macOS because Homebrew prevents modifying the user environment.

Current behavior

Currently, extensions are installed and discovered through pup’s extension directory and manifest model. This works, but it means an executable already available on PATH like:

pup-foo

does not automatically show up as:

pup foo

unless it is separately registered or installed through pup.

Proposed model

pup would discover extensions from:

1. The user’s PATH
2. Explicit discovery paths stored in pup config/state
3. Legacy manifest entries imported during migration

There would be no requirement to create or manage a pup-specific extensions/bin directory.

Any executable named pup- could appear in:

pup extension list
pup --help

but it would not be runnable with Datadog auth until explicitly enabled.

Enable / disable UX

To allow an auto-discovered extension:

# both are the same, pin the hash of the extension executable and enable it
# when the executable hash changes (e.g. due to an update) it won't be callable anymore
pup extension enable foo
pup extension enable foo --trust-scope exact

# pin the path. Allows in-place updates e.g. via brew, even if the hash changes
pup extension enable foo --trust-scope path

# pin the executable name. Any "pup-foo" executable will be allowed, no matter the hash/path
pup extension enable foo --trust-scope name

# not callable anymore
pup extension disable foo

Trust scopes:

• exact: allow this resolved path and current SHA only
• path: allow this resolved path, including future SHA changes
• name: allow any discovered executable named pup-foo

Default would be exact.

This matters because extensions receive Datadog auth credentials through the environment when run. An unenabled extension should fail closed in
noninteractive contexts.

Migration from manifests

Note: could be worth skipping migration, since I doubt these are used currently.

If we want to migrate legacy extensions, then we would on first run:

1. Read legacy manifests.
2. Auto-enable the executable (using trust mode exact)
3. Add extension path to the extension "auto discovery" paths (so that extensions not in PATH are still discovered via the new system)

[jkirsteins]

I think there is value in this type of discovery also because delivering via e.g. Homebrew means benefitting from its dependency management capabilities.

However that's a larger change, so meanwhile proposing this improvement for the existing extension flow: #593 (i.e. allowing multiple extensions to be installed via github, including from private repos)