https://pantsbuild.org/ logo
Join Slack
Powered by
<@UKPS08ZGW>: v2 list is here: <https://github.com...
# development
w
(files named 
register.py
are loaded via the mechanism explained here: https://www.pantsbuild.org/howto_plugin.html#simple-configuration , but that is a tangent, because you should just follow the example of 
list
in this case)
@hundreds-breakfast-49010: the reason https://github.com/pantsbuild/pants/blob/056e60fbfb7c90af3dba6f605d09f6a34bd63bff/src/python/pants/rules/core/list_targets.py#L33-L88 ends up named 
./pants list
on the CLI is because it returns an instance of `Goal`: 
ListGoal
in this case
h
@witty-crayon-22786 I'm looking at d064804b3acf89a30fefae3f6900f0414e3e3416, which is the commit where you converted the 
list
goal to a 
console_rule
and I can't figure out how you determined that 
[Console, List.Options, Specs]
was the right set of input selectors to use
I'm also not sure how I can get a reference to 
context
in the new version of the rule
w
Because those were the things that the rule needed to run
The Context is gone: it's a v1 concept. Instead, v2 rules explicitly say what they need via their arguments
If you need the "TargetRoots" subsystem to run, you'd say so with your argument selectors
(and install it as an 
optionable_rule
)
h
I think I want the 
SourceRoots
subsystem, right?
the v1 rule is calling 
self.context.source_roots.all_roots()
, so I want to request 
SourceRoots
as an argument selector and then call 
all_roots()
on that in the new rule, right?
not 
TargetRoots
?
w
Yea, probably
h
I get the following error running `./pants goals`: " 
No rule was available to compute SourceRoots with parameter types (Address+BuildFileAddress+BuildFileAddresses+Console+Digest+DirectoriesToMerge+DirectoryWithPrefixToStrip+ExecuteProcessRequest+LLVM+NativeToolchain+OptionsBootstrapper+OwnersRequest+PathGlobs+Scope+Specs+ToolchainVariantRequest+UrlToFetch)
w
Need an optionable_rule for SourceRoots
h
what is 
optionable_rule
doing exactly?
it looks like that is being used to wrap the outputs of 
def rules()
declaration lists
not the input arguments for a 
@rule
w
It creates a rule that creates the subsytem
h
what is a subsystem conceptually?
it looks like wrapping 
SourceRoots
in 
optionable_rule
only works if it's a class that inherits 
Subsystem
?
w
Working?
(Subsystem extends Optionable, meaning that it holds option values: optionable_rule creates a rule that will parse those options to provide a subclass of Optionable: in this case the SourceRoots subsystem)
h
hm, maybe the 
SourceRoots
I've been looking at in 
pants/source/source_roots.py
isn't the right one?
that does not subclass 
Subsystem
maybe that's the v1 version?
w
Ah. I think maybe it is SourceRootsFactory or something?
h
SourceRootFactory
is defined in teh same file but doesn't subclass 
Subsystem
either
SourceRootConfig
does
w
Ah. K. That then.
Sorry, have been on my phone at the dentist
h
okay, so I need to have the 
rules()
function return 
optionable_rule(SourceRootConfig)
, so that there's a rule that provides 
SourceRootConfig
and then also have 
SourceRootConfig
be an input to my new v2 
list_roots
rule
so that within that function I can call something on it to get the list of roots and the print that to console, right?
but it's 
SourceRoots
that defines 
all_roots
, not 
SourceRootConfig
oh maybe I need to instantiate 
SourceRoots
within the function from the 
SourceRootConfig
provided as an input, and then use it immediately, without specifying it as a rule input or output
w
Should work, yea.
Can worry about reuse when there is more than one @rule consuming it.
h
alright, cool, I think that works
I'm working on a test for this now (and deleting the old version of the test)
I think the right place for it is a new file in 
tests/python/pants_tests/backend/python/tasks
?
and it looks like the BUILD file there has manually-created enteries for each individual test file? so I'd have to make one myself?
w
yes re the BUILD file.
re: the location. this won't be a 
task
anymore, so that name isn't really accurate.
if you look at what i did with `listtargets`: the gist of how testing changes is to move from 
ConsoleTaskTestBase
to 
ConsoleRuleTestBase
h
yeah I'm looking at that as an example
so that's in 
pants_test/backend/graph_info
I don't know if the new version of 
roots
is a 
graph_info
concern
w
tis
"graph info" is pretty nebulous. but it still fits i think.
h
I've added a test: https://github.com/gshuflin/pants/commit/07b902b077921da9a19d9927d39b8952ec8ffd07 based off the existing one, but when I actually run this with 
/pants test tests/python/pants_test/backend/graph_info/tasks:roots
I get emtpy lists for all the console output tests
which makes me think I'm somehow not initializing the test correctly
hm is it possible that 
params = Params(specs, console, options_bootstrapper)
in 
console_rule_test_base.py
isn't general enough?
that looks like it was written specifically for the 
list_rules
test
which is the only thing using 
ConsoleRuleTestBase
so far
w
It is general enough
If it wasn't, the rule would fail earlier
Have you tested this on the CLI?
h
yeah, on the CLI it works exactly the same as the v1 rule
w
K. Yea, then those product requirements are fine
(and you're sure you uninstalled the old one?)
h
I'm currently calling this new rule 
rootsv2
to avoid namespace conflicts until I have everything working
but also yeah I deleted the old v1 code on this branch
and changing the name back to 
roots
doesn't magically make my new test stop failing
w
time to start adding debug output!
h
so I'm not doing anything obviously wrong here?
w
not that i can tell.
h
Okay, I've figured out that in my new code, something in 
source_root.py
is trying to add the pattern 
/src/go/src
instead of the 
fakeroot
that the old version of the code does
w
Consider posting a draft. My guess is that you are not using the SourceRootConfig that is being passed in
And are instead using the global one?
(I will say though: the SourceRoots case is a really weird one in v2, because it scans the whole working copy)
(not sure how that could contribute, but)
h
huh I didn't even know there was a global sourcerouteconfig
maybe that's what's going on
is it still the case that draft PRs are triggering travis builds?
looks like it is
Open in Slack
PreviousNext
Powered by