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.

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?

Yes, I'm talking about the

pex_binary

.

I see, you want a pex_binary to use a console script as its entry point

exactly

That seems very doable

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>

?

You can do

PEX_SCRIPT=<console_script> ./dist/sources/binary.pex <args>

Cool! Thanks.

Yeah, I noticed this hole a while back: https://github.com/pantsbuild/pants/issues/11619

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

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.

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

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.

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

True. A difference being that plugin API allows you to have classes, whereas BUILD files are restricted to primitives like strings.

I can't see why we'd have the same criteria for BUILD grokkability and code.

General consistency of terminology is preferable when possible.

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

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.

@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!

Cool! Thanks! :)