run
Run a pex_binary target.
To run an executable/script, use pants run on one of the following target types:
(See package for more on the pex_binary target.)
# A python_source target (usually referred to by the filename)
$ pants run project/app.py
or
# A pex_binary target (must be referred to by target name)
$ pants run project:app
To pass arguments to the script/executable, use -- at the end of the command, like this:
$ pants run project/app.py -- --arg1 arg2
You may only run one target at a time.
The program will have access to the same environment used by the parent pants process, so you can set environment variables in the external environment, e.g. FOO=bar pants run project/app.py. (Pants will auto-set some values like $PATH).
Pants will propagate the return code from the underlying executable. Run echo $? after the Pants run to see the return code.
Run pants dependencies --transitive path/to/binary.py to ensure that all the files you need are showing up, including for any assets you intend to use.
Execution Semantics
Running a pex_binary is equivalent to package-ing the target followed by executing the built PEX from the repo root.
Running a python_source with the run_goal_use_sandbox field set to True (the default) runs your code in an ephemeral sandbox (temporary directory) with your firstparty code and Pants-generated files (such as a relocated_files or archive) copied inside. If you are using generated files like this, you may need to set the run_goal_use_sandbox to True for file loading to work properly.
Running a python_source with the run_goal_use_sandbox field set to False is equivalent to running the source directly (a la python ...) with the set of third-party dependencies exposed to the interpreter. This is comparable to using a virtual environment or Poetry to run your script (E.g. venv/bin/python ... or poetry run python ...). When scripts write in-repo files—such as Django's manage.py makemigrations - it is often necessary to set run_goal_use_sandbox to False so that the file is written into the expected location.
Watching the filesystem
If the app that you are running is long lived and safe to restart (including web apps like Django and Flask or other types of servers/services), you can set restartable=True on your pex_binary target to indicate this to Pants. The run goal will then automatically restart the app when its input files change!
On the other hand, if your app is short lived (like a script) and you'd like to re-run it when files change but never interrupt an ongoing run, consider using pants --loop run instead. See Goals for more information on --loop.
Debugging
- In your editor, set your breakpoints and any other debug settings (like break-on-exception).
- Run your code with
pants run --debug-adapter. - Connect your editor to the server. The server host and port are logged by Pants when executing
run --debug-adapter. (They can also be configured using the[debug-adapter]subsystem).
First, add the following target in some BUILD file (e.g., the one containing your other 3rd-party dependencies):
python_requirement(
name = "pydevd-pycharm",
requirements=["pydevd-pycharm==203.5419.8"], # Or whatever version you choose.
)
You can check this into your repo, for convenience.
Now, use the remote debugger as usual:
- Start a Python remote debugging session in PyCharm, say on port 5000.
- Add the following code at the point where you want execution to pause and connect to the debugger:
import pydevd_pycharm
pydevd_pycharm.settrace('localhost', port=5000, stdoutToServer=True, stderrToServer=True)
Run your executable with pants run as usual.
Note: The first time you do so you may see some extra dependency resolution work, as pydevd-pycharm has now been added to the binary's dependencies, via inference. If you have dependency inference turned off in your repo, you will have to manually add a temporary explicit dependency in your binary target on the pydevd-pycharm target.