Is there a reason Lektor is so strict about plugin distribution names?

This pertains to the relationship between plugin name and package name which is enforced by lektor.pluginsystem.load_plugins().

Motivating Story

I have a package called excerpt-html, which, essentially contains one python function (not surprisingly named excerpt_html) whose purpose is to compute excerpts (or “summaries”) of HTML text fragments. I thought it would be nice to include a simple Lektor plugin in the package. The plugin would register a single jinja filter (also called excerpt_html) which would allow excerpts to be computed within jinja templates.

So I write a lektor plugin, and add something like this to setup.py:

entry_points={
    'lektor.plugins': [
        'excerpt-html = excerpt_html.lektor:ExcerptHtmlPlugin',
    ]
}

When I go to use this, this error message obtains:

lektor/pluginsystem.py:123: in initialize_plugins
E RuntimeError: Mismatching entry point name.  Found "excerpt-html" but expected "-html" for package "excerpt-html".

Points and Questions

First off, note that the error message is rubbish. The problem is not the name of the entry point, but rather (for the most part) the distribution name of my package. There seems to be no way to pass muster unless the distribution name starts with lektor-. (The message claims that Lektor expects the plugin to be named -html, but it’s clear that it won’t be happy with that name either.)

Second, is there really a good reason to require a specific relationship between distribution name and plugin name? Why shouldn’t I be able to register a plugin named excerpt-html in my excerpt-html distribution?

It seems silly to have to create a whole new distribution (lektor-excerpt-html) just to package the (essentially three-lines of) Lektor plugin code. Do I have any better options?

[runfalk]

It’s easy to enforce plugin names, but it’s harder to enforce trove classifiers. I like the explicit prefix since it signals that this package is intended to be used with Lektor. Your particular library might be multi purpose, but removing the restriction means that anyone can publish something that only works with Lektor, yet is not prefixed. Of course anyone can create a package with the prefix, whether or not it is a plugin, but it’s a way to alert the user that they are trying to do something that doesn’t quite make sense.

Apparently we allow the user to install plugins that are not prefixed with lektor-, and that sounds like a bug to me. I don’t think there is a clean way to check for plugin specifiers before installing it.

The prefix requirement is also part of how lektor create plugins (https://www.getlektor.com/docs/plugins/dev/).

If your plugin is only 3 lines I’d probably just create it as part of the site and keep it the packages/ directory. To me, your particular case sounds very unique and I don’t think it’s a good idea to change Lektor to accommodate a single project. I’m happy to keep the issue open for further discussion though. Maybe other maintainers have a different opinion.

[dairiki]

@runfalk wrote, some time ago

It’s easy to enforce plugin names, but it’s harder to enforce trove classifiers.

I don’t think that’s particularly true, especially now that we’re using importlib.metadata rather than pkg_resources to access the distribution metadata. We still, essentially, have to find the distribution metadata for the plugin to check the distribution name. Once we have the distribution metadata, accessing the classifiers is not fundamentally any more difficult than accessing the distribution name. The test, assuming dist is an instance of importlib.metadata.Distribution is:

has_lektor_classifier = "Framework :: Lektor" in dist.metadata.get_all("classifier")

If we really care that we should be able to find all Lektor plugins on PyPI, what about just requiring plugins to come from a distribution tagged with the Framework :: Lektor trove classifier? (I still feel that’s being awfully pushy, but at least it is a less onerous requirement.) PyPI appears to support searching by classifier just fine.