hm. i finally see why people aggressively re-expor...
# development
w
hm. i finally see why people aggressively re-export
@rules
when they think that they are going to need them.
h
what do you mean?
w
example:
Copy code
src/python/pants/backend/python/lint/bandit/rules.py
156:def rules():
157-    return [
158-        bandit_lint,
159-        bandit_lint_partition,
160-        SubsystemRule(Bandit),
161-        UnionRule(LintRequest, BanditRequest),
162-        *download_pex_bin.rules(),
163-        *determine_source_files.rules(),
164-        *pex.rules(),
165-        *python_native_code.rules(),
166-        *strip_source_roots.rules(),
167-        *subprocess_environment.rules(),
168-    ]
(it makes for less boilerplate in tests)
not sure how i feel about it, but… i feel the pain of not doing it, heh
h
Oh yeah. My suggestion has been that you re-export the rules you directly use. Like
external_tool.py
would re-export
archive.py
so that no own needs to register it as a transitive dependency
w
“directly use” is a bit fragile, but yea i guess you have to do something
a
i would like it if everything annotated with
@rule
could be assumed to be available to use from any other rule
i think dependency inference may allow us to forgo the current
def rules():
approach if we want to go that route
also, i think the
@rule
annotation might be calling
inspect.stack()
and generating an ast once per rule, as opposed to once per file. but i don't think that should be a concern as i would prefer to focus on making pantsd more reliable than import time improvements right now -- i'm working on a side project to improve python import time anyway
h
The only part where that wouldn’t work great is tests. We want tight control of tests for hermiticy imo
a
yes! we would definitely want to control the universe of v2 rules brought in for testing. the API there could stay the same i think, with explicitly registering rules
i'm not sold on this idea yet, i should make a doc