https://pantsbuild.org/ logo
Join Slack
Powered by
With the `run` PR <https://github.com/pantsbuild/p...
# development
h
With the 
run
PR https://github.com/pantsbuild/pants/pull/15849, 
[python].tailor_pex_binary_targets
is no longer very useful. Thoughts on what should happen? cc @happy-kitchen-89482
🎉 1
Related, 
pex_binaries
seems less useful. There is some complexity to keeping it around, like that the generated addresses are more complex. More to document. cc @bitter-ability-32190
b
I have a real world use case of using the generator for real package-ables, but I can get away with one per 🤷‍♂️
h
With Andreas's new 
__defaults__
, is it still helpful for you to have?
b
Yeah. It's multiple binaries in a dir,
w
pex_binaries can probably already be replaced with parametrize
🤔 1
b
That's true. Although it's asymmetrical to the other generator targets. And wouldn't work for the overrides field, right?
w
Yea, wouldn't have overrides
b
It really is multiple binaries so a generator is most correct here
➕ 1
h
Yeah I think it's fine if we want to keep the generator. It's a valid use of the mechanism
Sounds like everyone agrees on getting rid of 
tailor
for 
pex_binary
though? I'm not sure how we deprecate that. it would be annoying to require people to explicitly set it in order to change the default w/o breaking deprecation policy
➕ 1
b
Depreciation warning if the python option for tailoring PEX binary is true?
Oh I guess that's the default. I think that's ok to deprecate and warn. Maybe only if we end up tailoring a pex binary?
h
I don't know that I agree about getting rid of `tailor`ing pex_binary
Or are you suggesting changing the default?
but keeping the capability
b
To me, it's kind of like the infer init thing. Some python scripts are just scripts and some are real applications to package. If someone turns on tailor how do we ensure we don't blast their scripts as binaries?
Which doesn't say whether we should deprecate or not. Just highlighting a fhallenge
h
Yeah
Hmm
Open in Slack
PreviousNext
Powered by