https://pantsbuild.org/ logo
Join Slack
Powered by
I'm looking to add an option to `pants` to have a ...
# plugins
b
I'm looking to add an option to 
pants
to have a "strict constraints" mode and will likely need some friendly nudges by the Pants devs to navigate the codebase. Ideally in "strict_constraints" mode, all of a Python source's dependencies must exist in the 
requirements_constraints
file. This ensures nobody adds a dependency to a script without also adding it to the constraints file. (Additionally, this will help in migrating to 
pants
as it's hard for me to see which modules aren't getting found automagically and require a 
module_mapping
entry).
I see in 
src/python/pants/backend/python/util_rules/pex_from_targets.py
where the code is able to identify "unconstrained projects", however it appears that will only trigger for explicitly specified requirements through the 
dependencies
arg
w
i haven’t thought about this a whole lot, but the first thing that comes to mind is confirming that there are owning targets for all import statements, which is something that you could do as part of inference: https://github.com/pantsbuild/pants/blob/6bf2002f257d873d633c374aef11568a38d75942/src/python/pants/backend/python/dependency_inference/rules.py#[…]0
👀 1
dependency inference is taking all import statements and looking them up in a mapping: if it does not find a match, the current behavior is not to log anything or otherwise error, because if the missing dependency represents something erroneously missing, then your build will fail later at runtime / in-mypy / etc
b
That makes sense to me, and would've taken me a while to arrive at that 🙌
w
(i.e., it’s safe, because it’s an under-estimate of your deps, and any not present won’t be in the sandbox)
if you instead had a mode to warn or fail there (with an excludelist bootstrapped from the stdlib), that would have the effect of requiring target definitions for all imports.
🙌 1
in practice, i’m not sure how much of a pain in the butt it will be. but very, very easy to try out.
b
Yeah, let's just say I don't have a lot of faith in our unit tests having enough coverage to find these. Additionally this raises confidence that my 
module_mapping
I'm defining will be correct (and therefore won't cause issues for devs being onboarded to 
pants
), or that new code which should be updating the global reqs is
w
also: this is something that we would love to have upstream if you’re able. but failing that, if you were to copy the inference rule with a new 
@union
member, and then… basically just fiddle with that last loop to warn/fail for zero matches… you could install both the original and your new one in a plugin
b
I'm happy to flounder around on this, and don't feel bad to eviscerate me in PR. I want to contribute to Pants and I learn best by diving in so it's all a learning exercise with the nice benefit of possibly adding value 🙂
💯 1
👍 1
I plan on upstreaming 🙌
❤️ 3
(I'm in #plugins just because it seemed the most relevant)
c
I tend to do the same, learning by doing ;)
❤️ 1
4 Views
Open in Slack
PreviousNext
Powered by