Aha, looks like I just pass `[sources_field]` and ...
# development
a
Aha, looks like I just pass
[sources_field]
and the
GlobMatchBehavior
gets auto-magic’d because it’s a singleton?
w
correct. that is the same mistake Danny made, which inspired the current work on https://github.com/pantsbuild/pants/issues/5788
a
Cool 🙂
Is the plan there that
GlobMatchBehavior
will become a variant?
w
just that both the SourcesField and the GlobMatchBehavior are parameters
and "singletons" in their current usage become something like default parameters
(not 100% sure of the UX yet, working bottom up)
a
Sounds good 🙂
In this case, it’s also a little weird that
GlobMatchBehavior
is a separate parameter, because it’s already a field on
PathGlobs
which a
SourcesField
has, so presumably whatever’s constructing the
SourcesField
should be looking up the default, rather than it being a Singleton that’s side-injected?
w
that sounds right.
...and probably is?
a
As far as I can tell, we always construct
PathGlobs
with the python default from the datatype, and then
hydrate_sources
overrides it with the Singleton value
So if they happen to be the same (which they do), it works out, but it’s definitely room for error 🙂
w
ah. yea.
a
i think you're totally right, the reason it ended up that way i think was because i didn't realize i could add the GlobMatchErrorBehavior to PathGlobs until later (thinking that might be a big interface change) and in the second iteration of that PR i was passing in the behavior separately -- in that case, it seemed to make sense to make it a singleton, but like you've discussed i don't think we need that structure now. that was something i could have caught while refactoring