https://pantsbuild.org/ logo
Join Slack
Powered by
The per-resolve config project motivates fixing a ...
# development
h
The per-resolve config project motivates fixing a problem we've had for a while: 
[GLOBAL].plugins
and 
[mypy].extra_type_stubs
don't currently give any mechanism to set a lockfile 🧵
Thus, they do not have a resolve name, so no way to reference them with the options like 
[python].resolves_to_find_links
. With the design from https://docs.google.com/document/d/1HAvpSNvNAHreFfvTAXavZGka-A3WWvPuH0sMjGUCo48/edit#heading=h.n451mfzergzm for "What if I don't use resolves / lockfiles", I believe we want to have a consistent way to set these options specifically for the two things. Sure, you can use 
__default__
, but we should also allow more granularity. This is similar to the proposed 
no-user-resolve
key for user code when you don't use 
[python].resolves
Does that make sense? Again, you aren't forced to use a lockfile, but now you can if you want, which is a good thing.
cc @ancient-vegetable-10556, I don't know if adding a lockfile for 
[GLOBAL].plugins
is going to complicate your work?
Cool, MyPy lockfile is working out well 🙂 https://github.com/pantsbuild/pants/pull/16461
a
@hundreds-father-404 Unlikely
👍 1
Should be entirely fine
h
Great, thanks! I'll get started on this as my next step in this project then
bike shed: thoughts on the resolve name for the lockfile for 
[GLOBAL].plugins
? 
global-plugins
, 
global-pants-plugins
, 
pants-plugins-option
? I think 
pants-plugins
is very likely to be claimed already by plugin authors with 
[python].resolves
I personally like 
pants-plugins-option
. Or 
global-plugins-option
. Seems the most clear
e
Is this dance suggesting a bomb we have out there in general? Users can pick any resolve name. Clearly they stay away from pre-existing Pants land-grabs, but we can add new ones to the core, they pgrade Pants and boom.
h
Usually the only time we add new names are by introducing new backends, which are optional. But indeed, 2.14 is adding 
mypy-extra-type-stubs
, this Pants plugins resolve, and I'm proposing 
no-user-resolve
and 
pep-517-build-backend
too. With our current code, that means every PexRequest will have an associated resolve. Theoretically, we could need to add new resolves to existing backends, though We have code that eagerly checks and errors on ambiguity.
Hm, adding this lockfile intersects with some tricky things Stu has worked on, and he's out till Monday. I'm going to wait on the lockfile support & do an incremental step to unblock the project
p
Can I have 
[GLOBAL].plugins
use my 
pants-plugins
resolve which covers code under 
pants-plugins/
? In my repo, they're effectively the same thing, and if there are any conflicts between 
pants-plugins
and what is in 
[GLOBAL].plugins
then I need to catch that sooner rather than later because everything in 
pants-plugins
is expected to be sourced in 
[GLOBAL].plugins
.
h
That's an interesting question. I'm gonna punt on implementing the plugins lockfile for now tbh because it so complex, and no longer is blocking me
🏈 1
p
So, I would vote that 
[GLOBAL].plugins
use the 
pants-plugins
resolve, but allow BUILD files to use that same resolve as well.
Open in Slack
PreviousNext
Powered by