Q: any reason why not using

req.key

here, rather than

<http://dist.as|dist.as>_requirement().key

? (shouldn’t they be the same?): https://github.com/pantsbuild/pants/blob/355d873899f31165a4e2ff1b84bc9aa3fb1c5575/src/python/pants/init/extension_loader.py#L99

build_configuration.register_rules(req.key, rules)
        loaded[dist.as_requirement().key] = dist

No reason afaict. My homework: + Pants main setuptools version: https://github.com/pantsbuild/pants/blob/355d873899f31165a4e2ff1b84bc9aa3fb1c5575/3rdparty/python/lockfiles/user_reqs.txt#L247-L249 + Distribution.key: https://github.com/pypa/setuptools/blob/v57.5.0/pkg_resources/__init__.py#L2635-L2641 + Distribution.as_requirement(): https://github.com/pypa/setuptools/blob/v57.5.0/pkg_resources/__init__.py#L2832-L2839 + Requirement.key: https://github.com/pypa/setuptools/blob/v57.5.0/pkg_resources/__init__.py#L3097

Ah.. ok. That was another reflection, that it was a dict storing `dist`s, but those values where never used either…

I think the proof point is that none of the plugin distributions published back then are useable with Pants today.

However, the

load_after

feature could be useful for plugins not yet written, I suppose..

That's the sort of useful though that's horrible - a last resort. It would be great if there was some better way to deal with conflicts. If you have to get titchy with load order - that's pretty unsustainable in general.

Ah, I think more of dependencies than load order, so

load_after

isn’t the best feature, then..

Yeah - that should be solvable by a well defined lifecycle that plugins are run through after being loaded on the sys.path.