Should `SecondaryOwnerMixin` mixin be ignored for ...
# development
b
Should
SecondaryOwnerMixin
mixin be ignored for the
run
goal? Right now
pex_binary
is no longer a secondary owner of a
python_source
which sucks for other goals, but is required because otherwise
run
would be ambiguous.
CC @witty-crayon-22786 @hundreds-father-404 @happy-kitchen-89482
h
Can you remove SecondaryOwnerMixin from the Pex entry point field instead?
b
I originally did, but it's weird, because we have other secondary owners of python sources that are still there, because they dont participate in
run
.
Felt weird to boot
pex_binary
just because its runnable
bump 🙂
w
um, iirc,
run
was sortof why
SecondaryOwnerMixin
existed in the first place
although i suppose that it is also helpful for
check
/
lint
… but definitely less so.
b
The docstring makes me believe it also exists to make
--changed
more match-y
h
I added it because
pex_binary
used to have a
source: str
field, and this was how we were able to migrate it so instead a
python_source
target would own that file, but you could still just the same
run
and
--changed-since
the binary
b
I think in this case, if we remove it: •
list
and
--changed-since
no longer see it (API change) • It doesn't mirror other secondary owners like
python_awslambda
w
--changed-since
isn’t really relevant in this case..? if you’re using
--changed-dependees
and the file changes, you’ll see the binary. and if the binary definition changed directly, you’ll see it
(there is still a dependency here, regardless of “ownership”)
b
Right, but without using
--changed-dependees
the specs pre-2.15 are different. Which matter to goals like
list
I guess I should've made a bigger point here that currently 2.15 breaks User API without doing this 😐
The PR is a week old now 😬
w
@hundreds-father-404: can you take a look at this one?
🙏 1