x- plugin convention is confusing

[Gustavo Niemeyer]

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?

[Mark Shuttleworth (sabdfl)]

Agreed, my expectation was that the plugin would be referred to as x-foo
in the part, not foo.

Mark

[Kyle Fazzari (kyrofa)]

Note that this functionality is documented here: https://github.com/snapcore/snapcraft/blob/master/docs/plugins.md

The idea is to deal with the potential clash between snapcraft's plugins and local plugins:

1. If one names their plugin foo.py and refers to it as `foo` in the yaml, if snapcraft includes a foo.py plugin as well snapcraft's will be preferred.
2. If one names their plugin x-foo.py and refers to it as `foo` in the yaml, if snapcraft includes a foo.py plugin as well the local one will still be preferred.

However, I agree that `x-*` is not intuitive, and I've never hit a situation where (1) was important functionality. My suggestion is to simply always prefer the local plugins upon clash, and get rid of the `x-*` prefix. Thoughts?

[Sergio Schvezov (sergiusens)]

El 30/06/16 a las 09:21, Kyle Fazzari escribió:
> Note that this functionality is documented here:
> https://github.com/snapcore/snapcraft/blob/master/docs/plugins.md
>
> The idea is to deal with the potential clash between snapcraft's plugins
> and local plugins:
>
> 1. If one names their plugin foo.py and refers to it as `foo` in the yaml, if snapcraft includes a foo.py plugin as well snapcraft's will be preferred.
> 2. If one names their plugin x-foo.py and refers to it as `foo` in the yaml, if snapcraft includes a foo.py plugin as well the local one will still be preferred.
>
> However, I agree that `x-*` is not intuitive, and I've never hit a
> situation where (1) was important functionality. My suggestion is to
> simply always prefer the local plugins upon clash, and get rid of the
> `x-*` prefix. Thoughts?

We went back and forth on this a lot. This is the original implementation, then we allowed only naming them x-foo which others found unintuitive, then we just went with no `x-` at all which had another camp confused.

The "x-" means not official, I don't mind readding x-foo as a plugin name, I would actually prefer that.

[Gustavo Niemeyer (niemeyer)]

Speaking from the user perspective, it took me a while to even understand what snapcraft was doing. I definitely expected the file name and the plugin name to match, which seems like the straightforward choice. Anything else is magic that needs to be understood.

Speaking from the designing perspective, point (1) above (from Kyle) is a bug IMO. If there is a local plugin named x-foo, it should be respected at all times, even if there's a standard plugin named foo. That's in fact the only reason it'd make sense to name the plugin with the x- prefix. If we implement an order of precedence, then the developer would have everything with the same name and not bother about introducing a disambiguation prefix.

[Kyle Fazzari (kyrofa)]

Note that (1) is with the local plugin named foo.py, not x-foo.py. What you specified is (2).