Use the builtin plugin classes unless another plugin class is specifically asked for.

[AWhetter]

What's the problem this feature will solve?

I have a private plugin for virtualenv where I add an additional discovery class. This discovery class adds a new argument to the command line parser that is required but only when the discovery class is chosen. However I'm seeing an issue where using virtualenv via the command line as normal is now asking for this argument. The reason seems to be that virtualenv is picking a default discovery class but in a non-deterministic way and sometimes the additional discovery class is chosen as the default discovery class and so the argument is required. The default class is chosen depending on which entry point is discovered first. I believe entry points give no guarantees about order of discovery.

The order of entry points discovery seems to change in different installs of virtualenv and the plugin, rather than changing in the same environment between different invocations of virtualenv.

I believe the problem will be the same for creators, seeders, and activators as well.

Describe the solution you'd like

I would expect the builtin discovery class to be chosen as the default discovery class unless explicitly set otherwise.

Alternative Solutions

These classes could have a priority set at the class level. The builtin classes would have a priority set such that a plugin class could opt to set it's priority lower or higher than the builtins. virtualenv would then order these classes by their priority. Classes would be allowed to have the same priority with the understanding that the order of classes with the same priority value would be non-deterministic.

[gaborbernat]

A PR achieving this would be welcomed and reviewed 👍🏻

[gaborbernat]

Released via https://pypi.org/project/virtualenv/20.4.4/