Skip to content

feat(build): let a plugin own a package's install command - #6

Merged
Sunrisepeak merged 1 commit into
mainfrom
feat/plugin-owned-install-command
Aug 14, 2026
Merged

feat(build): let a plugin own a package's install command#6
Sunrisepeak merged 1 commit into
mainfrom
feat/plugin-owned-install-command

Conversation

@Sunrisepeak

Copy link
Copy Markdown
Member

Summary

The install_command_template is one index-wide string, so it can only express what is true of every package. Some ecosystems need this line to vary per package.

The case that surfaced it is dsh-index, whose packages install through the ecosystem's own tool with a per-package spec:

  • a bundle published to npm → dsh plugin --profile web add dsh-cc-tui@0.1.6
  • an unpublished one (50 of its 68) → dsh plugin --profile web add github:owner/repo#<40-hex>

No single template covers both, and only the plugin knows which applies.

_install_commands runs after every plugin hook and assigned unconditionally, so a plugin that set the command in on_package had it silently overwritten — the plugin API appearing to be ignored rather than a documented precedence rule.

It now skips a package whose command is already set.

Test plan

  • New test_plugin_may_own_the_install_command: a plugin claims one of the fixture's two packages. The claimed one keeps its command; the unclaimed one still gets the template, so opting one package in does not opt the whole index out.
  • Full suite: python3 -m pytest tests/ -q46 passed.
  • Backward compatible: no existing test changed, and a config with no plugin behaves exactly as before.

The install command template is an index-wide string, so it can only say
what is true of every package. That is the right default, but some
ecosystems need the line to vary per package.

dsh-index is the case that surfaced it. Its packages install through the
ecosystem's own tool, and the spec differs per package: a bundle
published to npm installs by name and version, while an unpublished
neighbour -- 50 of its 68 packages -- installs from a pinned git commit.
No single template covers both, and only the plugin knows which applies.

_install_commands ran after every plugin hook and assigned
unconditionally, so a plugin that set the command in on_package had it
silently overwritten. That reads as the plugin API being ignored rather
than as a precedence rule.

It now skips a package whose command is already set. A package no plugin
claims still gets the template, so opting one package in does not opt the
whole index out.
@Sunrisepeak
Sunrisepeak merged commit 409d601 into main Aug 14, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant