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

modern-wolf-36228

09/05/2021, 8:25 AM
Is there a way to add more complex `entry_point`s? For example with Gunicorn or alembic, I wish to not run them in code. Like the
pex -c
way.
h

happy-kitchen-89482

09/06/2021, 8:57 AM
Hi, I'm not sure I fully understand the question. Can you give a more specific example? Are we talking about
pex_binary
for example?
m

modern-wolf-36228

09/06/2021, 8:58 AM
Yes, I'm talking about the
pex_binary
.
Is there a way to do this on the
pex_binary()
?
h

happy-kitchen-89482

09/06/2021, 10:08 AM
I see, you want a pex_binary to use a console script as its entry point
🙌 1
I think this is not possible right now, but I think would not be hard to add, the underlying machinery supports it.
cc @enough-analyst-54434 ?
Presumably the console script would come from some 3rd party requirement of the
pex_binary
?
m

modern-wolf-36228

09/06/2021, 10:11 AM
exactly
h

happy-kitchen-89482

09/06/2021, 10:12 AM
That seems very doable
👍 1
m

modern-wolf-36228

09/06/2021, 10:14 AM
In case I don't have an
entry_point
(entry_pont="<none>"), is it possible to do something like
./dist/sources/binary.pex <console_script> <args>
?
h

happy-kitchen-89482

09/06/2021, 10:29 AM
You can do
PEX_SCRIPT=<console_script> ./dist/sources/binary.pex <args>
Almost all pex runtime options that are set at build time can be overridden with env vars
m

modern-wolf-36228

09/06/2021, 10:36 AM
Cool! Thanks.
e

enough-analyst-54434

09/06/2021, 2:17 PM
Yeah, I noticed this hole a while back: https://github.com/pantsbuild/pants/issues/11619
h

hundreds-father-404

09/07/2021, 7:20 AM
All we need to figure out is the modeling for this. Right now, we force you to set
entry_point
. Do we keep that field and use it for both
-m
and
-c
, with some syntax to differentiate? Have two fields, and require one is set but not both? If two fields, what do we name it? With those questions answered, it's trivial to implement
e

enough-analyst-54434

09/07/2021, 12:12 PM
If a key principle is Pants doesn't get between you and tools, then I think the modeling is answered. Since setuptools already uses console_scripts and scripts and Pex follows a similar principle and therefore uses
-c / --script / --console-script
flag, we have a tight name pool for a new field. Since the value of a script or console script can - and ususually does - collide with valid module names - which are valid entry_point values, we'd need to introduce syntax as you point out and that would be a Pants-ism you'd need to learn to use your existing tool knowledge - we just got in the way. I don't think we have mutex fields yet for any targets we ship, so this would be new in the codebase. Certainly mutex options are not new to users though.
👍 1
h

hundreds-father-404

09/07/2021, 1:03 PM
True, sg on
console_script
being a new field. And yeah,
entry_point
still makes sense given Pex's opt being
-m/-e/--entry-point
. To check my understanding of console scripts...I don't think we need any special syntax for file paths like we have with
entry_point
, right? Because console scripts come from the metadata of distributions, not from loose files. We could possibly implement dependency inference, that
-c black
infers a dep on
//:black
, but not sure how reliable that is since a console script's name need not == the dist's name
e

enough-analyst-54434

09/07/2021, 1:43 PM
To check my understanding of console scripts...I don't think we need any special syntax for file paths...
Correct.
We could possibly implement dependency inference,...
It should be deemed completely unreliable. The only way to dep infer would be to download all declared 3rdparty dists and then look at their metadata to see if they have a script or console script with the given name, then add a dep on that dist.
👍 1
1
And - on the name,
console_script
would be a lie, since Pex can accept a script or a console_script. These naturally share a namespace since they generate an entry in a venv's
bin/
dir. I think you have to pick
script
and explain it can be either since script is a generic word that accepts either use whereas console_script rejects the script use at 1st blush.
👍 1
h

happy-kitchen-89482

09/07/2021, 4:43 PM
This would be a bit different from what we did for PexRequest, where there is a single
main
field that takes one of two types
But I am OK with that discrepancy, since only a handful of plugin authors will care
h

hundreds-father-404

09/07/2021, 4:46 PM
True. A difference being that plugin API allows you to have classes, whereas BUILD files are restricted to primitives like strings.
e

enough-analyst-54434

09/07/2021, 5:01 PM
I can't see why we'd have the same criteria for BUILD grokkability and code.
1
h

happy-kitchen-89482

09/08/2021, 1:55 PM
General consistency of terminology is preferable when possible.
h

hundreds-father-404

09/09/2021, 3:07 AM
Any opinion on how to model setting no
entry_point
and no
script
? Thus far, we've required you set
entry_point="<none>"
to be extra explicit - a common gotcha seemed to be forgetting to set the entry point It would be overly verbose imo to make you do
pex_binary(entry_point="<none>", script="<none>")
. Seems weird to still require
pex_binary(entry_point="<none>")
, given that this is valid:
pex_binary(script="foo")
(where entry_point is left off)
we've required you set
entry_point="<none>"
to be extra explicit - a common gotcha seemed to be forgetting to set the entry point
I think the best we can do is give up on this?
pex_binary()
is now legal, and you'll hopefully figure out from docs that you're missing setting one of the two fields
e

enough-analyst-54434

09/09/2021, 3:57 AM
I'm totally fine with that. This is where supporting configuration parameters being things beyond
bool
,
int
,
folat
str
,
set
,
list
,
dict
though would make modeling straight forward. If we had the doc system to support exposed objects you'd use a single field, say
exe: MainSpecification
and expose
Script(script: str)
/
EntryPoint(module: str, func: str | None = None)
/
NoExe()
variants and force one. We seem to be FAPP hamstringing ourselves with ~json syntax even though we parse with Python.
1
h

hundreds-father-404

09/10/2021, 6:26 PM
@modern-wolf-36228 https://github.com/pantsbuild/pants/pull/12849 and the prework for this inspired a couple improvements, including improving cache reuse for
./pants package
🙂 thanks for the feature request!
m

modern-wolf-36228

09/10/2021, 6:49 PM
Cool! Thanks! :)
6 Views