https://pantsbuild.org/ logo
#general
Title
# general
h

hundreds-father-404

10/01/2020, 5:24 PM
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?
w

witty-crayon-22786

10/01/2020, 5:27 PM
it should wait till post 2.0
2
i think.
just because it’s easy to do later.
w

wooden-thailand-8386

10/01/2020, 5:28 PM
wouldnt it be easier to just keep the target name and set it inside as a parameter?
Copy code
python_tests(
   mode="pytest",
   ...
)
h

hundreds-father-404

10/01/2020, 5:31 PM
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
👍 1
w

wooden-thailand-8386

10/01/2020, 5:32 PM
ha! I see, that makes more sense now to me
h

hundreds-father-404

10/01/2020, 5:33 PM
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
w

witty-crayon-22786

10/01/2020, 5:34 PM
imo, doing this lazily when we get the second X for Y would be perfectly reasonable
because the second one won’t be named
python_tests
either, for example, so it won’t collide
a

average-vr-56795

10/01/2020, 10:20 PM
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...
👍 1
h

hundreds-father-404

10/01/2020, 10:21 PM
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
a

average-vr-56795

10/01/2020, 10:23 PM
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.
💯 1
w

witty-crayon-22786

10/01/2020, 10:25 PM
extremely minor counterpoint: naming it “pex binary” does mean that you have to explain pex earlier than you would otherwise
(ditto other tools where we currently have opinions.)
but yea, no strong objections. i think laziness would be better in this case, but am fine either way.
a

average-vr-56795

10/01/2020, 10:27 PM
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"
I guess the other option is to have
pex_binary
wrap an abstract
python_binary
so you can conceptually
./pants run
the thing, but to get a deployable you need to think about packaging formats
w

witty-crayon-22786

10/01/2020, 10:28 PM
yea. “binary” is in the name, “python” isn’t. you’ll still find it in the docsite pretty quickly, but
h

hundreds-father-404

10/01/2020, 10:28 PM
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.
a

average-vr-56795

10/01/2020, 10:28 PM
Which is kind of in line with the discussion about
archive
wrappers on the `build`/`package` PR
👍 1
w

witty-crayon-22786

10/02/2020, 12:08 AM
mm, also:
./pants run $pex_binary
won’t create a pex
h

hundreds-father-404

10/02/2020, 12:11 AM
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
w

witty-crayon-22786

10/02/2020, 12:36 AM
right. but we’re claiming that the type of the thing is a pex, but it only is when `package`d
(minor)