Hey y’all, thanks for your feedback on the

package

goal. One other disruptive change we want to do before landing 2.0: rename

python_binary

to

pex_binary

and

python_tests

to

pytest_tests

. Some reasons: 1. We likely want to support multiple binary formats and multiple test runners in the future, e.g.

pyinstaller_binary

. We should stop privileging the status quo. 2. More accurately model that Pants is an orchestrator for the tools you already use; we’re not inventing some binary format, which might be implied with the status quo. We know it’s disruptive. We’ll use a deprecation cycle + give a script or sed regex snippet to automatically fix this. Any thoughts on this?

it should wait till post 2.0

wouldnt it be easier to just keep the target name and set it inside as a parameter?

python_tests(
   mode="pytest",
   ...
)

Great question. It depends on if the metadata for Hypothesis is very different from Pytest or not. That is, if the “fields” for the target type like

timeout

make sense regardless of the mode you’re using. If it’s roughly the same, then we could use the same target. So, likely

python_tests

should not yet be changed, then. Until we have better scoped other test runners like Hypothesis I think we would still want to change

pex_binary

though. It has lots of very custom fields like

ignore_warnings

, which is specific to the Pex API. It’s likely that

pyinstaller_binary

has its own custom set of fields like that, specific to the Pyinstaller API. That is, it’s unlikely we’d want to use one target for multiple different types of binaries

ha! I see, that makes more sense now to me

Thanks for asking that question, that’s a really good improvement.

python_library

and

python_tests

are both very generic, they’re probably good names already In contrast,

python_binary

is much more generic than it really should be. It’s not any Python binary, it’s specifically metadata to convert your code into a Pex

imo, doing this lazily when we get the second X for Y would be perfectly reasonable

I'm on board with

pex_binary

, don't have super strong feelings about pytest either way - I can certainly see that there's a lot more overlap in semantics and fields between test runners. On the other hand, in v1 we had

junit_tests

not java or JVM...

Thanks! Any thoughts on timing for it? My thinking with now is to avoid new users having to rewrite lots of things. Even if we never ourselves add

pyinstaller_binary

, I still think

pex_binary

is a good name. It makes things more declarative. But I generally try to avoid premature changes etc

2.0 seems perfect - a time when a bunch of stuff is being changed, we're hoping to create relatively stable APIs, and we're using Python as an example of how other languages should be done in the future. Feels like a good precedent to set.

extremely minor counterpoint: naming it “pex binary” does mean that you have to explain pex earlier than you would otherwise

It feels like "pex" is the answer to the question "how do I deploy some Python", which is the same question that necessitates the question "what target do I use for deployable python"

yea. “binary” is in the name, “python” isn’t. you’ll still find it in the docsite pretty quickly, but

naming it “pex binary” does mean that you have to explain pex earlier than you would otherwise

I think this could be a good thing. I suspect we’ve been abstracting over Pex a little too much. At the end of the day, we are wrapping Pex. You are going to need to know what the project is and some of its basics. Being explicit about it might be more clear.

Which is kind of in line with the discussion about

archive

wrappers on the `build`/`package` PR

mm, also:

./pants run $pex_binary

won’t create a pex

What do you mean? If the user wanted a Pex created, they would run

./pants package $pex_binary

, I’m not sure they would expect

run

to duplicate that. I’m not seeing a big difference between

./pants run $python_binary

vs.

./pants run $pex_binary

in terms of user expectations

right. but we’re claiming that the type of the thing is a pex, but it only is when `package`d