https://pantsbuild.org/ logo
#development
Title
# development
c

curved-television-6568

12/22/2021, 2:26 PM
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
Copy code
build_configuration.register_rules(req.key, rules)
        loaded[dist.as_requirement().key] = dist
Oops, that analysis was to prove Distribution.key == Distribution.as_requirement().key. You asked why not use Requirement.key directly...
But also no reason afaict for that either.
đź‘Ť 1
In fact, the "load_after" the dict supports was introduced 7 years ago for v1 and I'm pretty positive we happily have no use for this any longer.
c

curved-television-6568

12/22/2021, 3:36 PM
Ah.. ok. That was another reflection, that it was a dict storing `dist`s, but those values where never used either…
e

enough-analyst-54434

12/22/2021, 3:38 PM
I think the proof point is that none of the plugin distributions published back then are useable with Pants today.
c

curved-television-6568

12/22/2021, 3:39 PM
However, the
load_after
feature could be useful for plugins not yet written, I suppose..
e

enough-analyst-54434

12/22/2021, 3:40 PM
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.
c

curved-television-6568

12/22/2021, 3:42 PM
Ah, I think more of dependencies than load order, so
load_after
isn’t the best feature, then..
Say I have a plugin that adds features (to another plugin)… then that wouldn’t make sense to load, unless the extended of plugin is also loaded.
But I think load order should not matter…
e

enough-analyst-54434

12/22/2021, 3:43 PM
Yeah - that should be solvable by a well defined lifecycle that plugins are run through after being loaded on the sys.path.
But really - if a plugin modifies another, then it depends on its types, so in the plugin resolve, the dependency graph naturally should handle all this.
đź‘Ť 1