x- plugin convention is confusing

Metadata

Project: snapcraft (launchpad)
Number: #1597603
Type: issue
State: open
Author: ~niemeyer
Labels: custom-plugin
Created: 2016-06-30 04:55 AM UTC
Updated: 2017-03-04 07:25 PM UTC
Closed: —

Current evaluation

Reports that the x- prefix on local plugin files (x-foo.py) is confusing: the plugin loads as 'foo' and the prefix doesn't disambiguate from remote plugins. No maintainer response in 10 years. The x- convention no longer exists in modern snapcraft.

Suggested action: close stale

Reason: The issue is 3715 days old with 0 comments and no maintainer interaction, and it targets snapcraft 1.x behavior: the x- prefix convention for local plugins was removed in snapcraft 2.x, where local plugins are placed in snap/local/plugins/ and referenced by plain name, so the reported shadowing concern no longer applies. The related Launchpad bug #1500873 was also closed as superseded by the updated specification. Confidence is moderate because repo code inspection was unavailable (no pinned SHA) to directly confirm the current plugin-loading code.

Impact: 10 Quick Win: 6.5 Staleness: 92 Complexity: 35 Confidence: 65 Support Request: 20

Issue body

It took me a while to understand that despite having the plugin named as x-foo.py in the plugin repository, it gets loaded as "foo" and must be referenced as such in snapcraft.yaml: % snapcraft snap Loaded local plugin for foo Searching for local plugin for x-foo Issue while loading plugin: unknown plugin: x-foo That seems to remove the point of having the x- prefix, which is to disambiguate local plugins from remote one. The local file name matters little. Doesn't that mean, for example, that if I use a remote part that happens to use a "foo" plugin, it will pick my local x-foo.py file instead of attempting to load a "foo" plugin from snapcraft itself?

Evaluation history

Date	Model	Scores	Action	Summary
2026-09-01 07:19 AM UTC	qwen/qwen3.8-27b	Impact: 10 Quick Win: 6.5 Staleness: 92 Complexity: 35 Confidence: 65 Support Request: 20	close stale	Reports that the x- prefix on local plugin files (x-foo.py) is confusing: the plugin loads as 'foo' and the prefix doesn't disambiguate from remote plugins. No maintainer response in 10 years. The x- convention no longer exists in modern snapcraft.
2026-07-23 11:47 AM UTC	qwen/qwen3.6-35b-a3b	Staleness: 95 Complexity: 25 Confidence: 90 Support Request: 10	close stale	Confusion over the x- prefix convention for local plugins in snapcraft and how they are referenced in snapcraft.yaml. The report has seen no maintainer activity or comments for over nine years.
2026-07-22 12:18 PM UTC	qwen/qwen3.6-35b-a3b	Staleness: 98 Complexity: 40 Confidence: 90 Support Request: 30	close stale	Confusion regarding the x- prefix convention for local Snapcraft plugins, which are loaded without the prefix. No maintainer response or activity in over 9 years.
2026-07-09 05:57 PM UTC	qwen3.6-35b-a3b-mtp-q6	Staleness: 95 Complexity: 35 Confidence: 85 Support Request: 25	close stale	Confusion over the x- prefix convention for local Snapcraft plugins. The prefix is stripped during loading, causing disambiguation issues and potential conflicts with remote plugins. No maintainer response in over 9 years.
2026-06-20 02:33 PM UTC	qwen3.6-35b-a3b-mtp-q6	Staleness: 98 Complexity: 20 Confidence: 90 Support Request: 70	close stale	Confusion over the x- prefix convention for local snapcraft plugins. Files named x-foo.py must be referenced as foo in snapcraft.yaml, risking unintended overrides of remote plugins. Open, unassigned, needs triage.

Update history

No update history recorded yet.

Related work

Related To: snapcraft (launchpad)#1500873 (confidence 70%)
Launchpad bug 'x-[plugin] is the correct way for a plugin to work' was closed as superseded by the updated specification revision that adopted the x-[plugin] naming convention this issue questions.

Related issues

No related issues found above the similarity threshold.