https://pantsbuild.org/ logo
Join Slack
Powered by
Is there any way to parametrize a pair of fields t...
# general
c
Is there any way to parametrize a pair of fields together? 🧵
Example:
Copy code
python_requirements(
  resolve=parametrize("a", "b"),
  dependencies=parametrize(a=["foo"], b=["bar"])
)
In other words, so that I don’t get the dot product of all parametrizations (which I expect I’ll get as it is above)..?
For the above I’d like to get just:
Copy code
python_requirements(
  resolve="a",
  dependencies=["foo"]
)
python_requirements(
  resolve="b",
  dependencies=["bar"]
)
h
There is not currently. This is where Stu's idea of "configurations" came in, but we intentionally didn't want to commit to that design yet. I think it could be fair game to come up with alternative implementations like what you have above
for now, you have to create N manual targets
c
Yea, I was prepared for that. Although, your suggestion to use 
_generator_sources_helper
is great in theory it was hard in practice due to there not being a 
dependencies
field on 
python_requirements
and I don’t know of a better way to inject that dependency on all 
python_requirement
targets as 
__defaults__
does not apply to generated targets.
Does 
overrides
take wildcards?
h
nd I don’t know of a better way to inject that dependency on all python_requirement targets as defaults does not apply to generated targets.
I thought it does?
Does overrides take wildcards?
Depends on the specific target generator. For source-based ones, yes it does. For python_requirements, it does not
c
doh..
h
it was hard in practice due to there not being a dependencies field on python_requirements
we could possibly add it. the only reason it's not there is thinking
it doesn't make sense generally to add python_requirement deps, other than for undeclared 3rd-party deps, which seems to be more a per-requirement issue.
it's only trying to be overly conservative so users don't add deps that they don't want. but probably it's fine here
Doesn’t seem so.. https://www.pantsbuild.org/v2.14/docs/reference-python_requirements
i don't understand why this docs passage implies defaults won't work?
c
ah, yea that makes sense, as you hardly want a dependency to something from all your 3rdparty libs.
➕ 1
but in my case I do 😛
➕ 1
i don’t understand why this docs passage implies defaults won’t work?
my bad, I misread your reply 😛 (I’ll double check the defaults behaviour on generated targets, going off of memory on that one)
👍 1
> I don’t know of a better way to inject that dependency on all python_requirement targets as defaults does not apply to generated targets.
I thought it does?
It doesn’t. It’s one of two irritating limitations of 
__defaults__
, the other one being that you can’t provide a parametrization as a default field value. https://www.pantsbuild.org/v2.14/docs/targets#field-default-values
Argh, I’ve not yet learnt the shape of the 
return
key on this keyboard, keep hitting it inadertently.. 😛
The default values link above to the docs ought to mention both of these limitations I think…
h
the alternative fix is adding 
dependencies
to 
python_requirements
target generator. then you could use defaults with 
python_requirements
for example, which is what the ticket talks about
👍 1
c
Ah, right. Yeah it should be handled in some way or another.. like detect if there are targets generated that has defaults then warn or something (unless we apply them… apparently old me thought that was a bad idea)
the root issue I’m working on is to partition the blast radius when changing 3rdparty deps (like updating the lockfile).. by leveraging resolves that works like a charm, but the missing link is to have a dependency from the lockfile to the targets using it.
So, I don’t think that we actually need to expose the dependencies field on python_requirements, if we manage to solve the above instead 😉
Open in Slack
PreviousNext
Powered by