Plugins with conflicting entry-point error-code specifications do not auto-load properly [REPLACEMENT ISSUE]

[asottile]

The original issue

Id: 534
Title: Plugins with conflicting entry-point error-code specifications do not auto-load properly

could not be created.
This is a dummy issue, replacing the original one. It contains everything but the original issue description. In case the gitlab repository is still existing, visit the following link to show the original issue:

TODO

[asottile]

In GitLab by @asottile on Apr 14, 2019, 23:06

yeah not sure if this is documented anywhere but the name has to be unique. The oddity with uninstall / upgrade / ordering is due to setuptools metadata being stored on the filesystem and so you have (~relatively undefined) ordering based on inode.

I think this is working as intended right now, though it would maybe be better if some sort of warning / error occurred in this case.

This is probably the most relevant line: https://gitlab.com/pycqa/flake8/blob/98beabdcc50ee352a8a5eded1009b0914a3645b9/src/flake8/plugins/manager.py#L276

[asottile]

In GitLab by @bskinn on Apr 14, 2019, 23:27

@asottile To be sure I understand you, is it that the B in both of these supposed to be a ~free-text name for the plugin? The 'name that has to be unique'? Because in most (all?) of the (few) plugins whose setup.pys I've looked at, that value has tended to be some representation of the error codes raised by the plugin. There may be a pervasive misunderstanding of the semantics of that identifier! This uniqueness requirement of the entry point name should probably be prominently called out in any official plugin-developers' how-to/tutorial...?

And, regardless, yeah, it seems like at minimum a warning should be emitted at execution time for plugin namespace collisions like this.

[asottile]

In GitLab by @asottile on Apr 14, 2019, 23:34

Actually yeah, now that I found the right docs page (I was looking at the using plugins page earlier!) it does seem to be prominently called out twice there:

http://flake8.pycqa.org/en/latest/plugin-development/registering-plugins.html

Flake8 requires each entry point to be unique amongst all plugins installed in the users environment. Selecting an entry point that is already used can cause plugins to be deactivated without warning!

This was part of the rationale for moving to allowing 3-letter codes in flake8 3.x

And yeah, upgrading / downgrading a package likely changes the inode ordering (try running os.listdir('.') on an arbitrary directory, the results are very unlikely to be sorted!)

[asottile]

In GitLab by @bskinn on Apr 14, 2019, 23:43

Unngh... So... This... collision behavior is intentional?

The X in checking plugins define what error codes it is going to report. So if the plugin reports only the error code X101 your entry-point would look like:

This seems like a problematically fragile semantics. Is the idea that this would avoid plugins reporting the same error codes? It...seems like a really awkward/incomplete/problematic approach, if so.

IMO the entry point name should be, e.g., the package name...MUCH more likely to be unique. If there's a desire to have some sort of machinery in place to avoid multiple things raising the same code, it would make more sense to me for plugins to register the codes they raise via some other parameter in the plugin registration handshake...then it'd be fully granular.

[asottile]

In GitLab by @bskinn on Apr 14, 2019, 23:44

And <nod>, I have noticed that listdir results are usually wildly unsorted. :-)

[asottile]

In GitLab by @asottile on Apr 14, 2019, 23:48

It's not so simple unfortunately -- that prefix is used by --enable-extension to turn on non-default plugins. It's also pretty ingrained into the plugin structure dating back to at least flake8 2.x so it's pretty unlikely to change.

I'm not sure that the behaviour is ~intentional so-to-speak, though it is at least known and documented. Ideally plugins would select unique reported error codes, though there isn't really any sort of centralized place to manage that (even if there was, that'd box out proprietary / closed-source plugins).

[asottile]

In GitLab by @bskinn on Apr 14, 2019, 23:56

Hrmmmm...so, the recommended best-practice is for plugin developers to switch to the multi-letter code prefixes? If so, a marketing push to try to coax devs of existing plugins to make that switch might be of some value...counterweighted by the users of the plugins potentially needing to update their configs, I guess.

And...as a user, I guess I just have to manually check every time I install a new plugin, that all of the plugins I expect do still show up on a flake8 --version? <shakes head> I may just put all of my desired plugins into [flake8:local-plugins], and just forget about the auto-load functionality, so that I don't have to be concerned about the whole thing. :-/

[asottile]

In GitLab by @asottile on Apr 14, 2019, 23:58

I think it's more that new plugins should pick the three-letter codes, assuming there aren't existing conflicts

[asottile]

In GitLab by @bskinn on Apr 15, 2019, 24:00

closed

[asottile]

In GitLab by @bskinn on Apr 15, 2019, 24:04

<nod>, makes sense.

In this case, which project would you recommend I approach first to switch codes, and avoid the collision? -pie is smaller and non-PyCQA, and so seems the more natural one to displace, but -bugbear might be more responsive, being PyCQA?

[asottile]

In GitLab by @asottile on Apr 15, 2019, 24:08

flake8-pie appears to be brand new so they should probably change, maybe suggest PIE as their prefix 😆?

(an aside, I'm hoping to get one of their rules directly into pyflakes here)

[asottile]

In GitLab by @bskinn on Apr 15, 2019, 24:16

Hehe, PIE was my thought, too. Ok, I'll start there. Thanks vm for your time!

Good luck with that PR...man, soooo many complex cases to consider...!