Setting up an IDE

---

If you use a code-aware editor or IDE, such as PyCharm or VSCode, you may want to set it up to understand your code layout and dependencies. This will allow it to perform code navigation, auto-completion and other features that rely on code comprehension.

First-party sources

To get your editor to understand the repo's first-party sources, you will probably need to tell it about the repo's source roots. You can list those with:

shell

$ ./pants roots

and then apply the corresponding IDE concept.

For example, in PyCharm you would mark each source root as a "Sources" folder. See Configuring Project Structure to learn more.

In VSCode, the Python extension will look for a file named .env in the current workspace folder. If the file is found, then it will be loaded and evaluated. This file can be used to set the PYTHONPATH variable. Having this file makes it possible to jump to definitions in the source code across multiple projects. It also makes cross-project refactoring possible.

To generate the .env file containing all the source roots, you can use something like this:

shell

$ ROOTS=$(./pants roots --roots-sep=' ')
$ python3 -c "print('PYTHONPATH=\"./' + ':./'.join(\"${ROOTS}\".split()) + ':\$PYTHONPATH\"')" > .env

See Use of the PYTHONPATH variable to learn more about using the PYTHONPATH variable in VSCode.

Third-party dependencies (Python)

To get your editor to understand the repo's third-party dependencies, you will probably want to point it at a virtualenv containing those dependencies.

You can use the export goal to create a suitable virtualenv under dist/export/python/virtualenv:

Shell

./pants export ::

and then point the IDE at the virtualenv. For example, in PyCharm you would select this virtualenv's bin/python as the Project SDK.

Note that this only works if a single consistent global resolve is possible for your repo. If not, you'll have to segment the set of requirements appropriately (e.g. ./pants export path/to/some/project::), generate multiple virtualenvs, and set up separate IDE modules for each.

Alternatively, you can export the requirements and build the virtualenv manually using something like:

shell

VENV=/path/to/venv
python3 -m venv "${VENV}"
"${VENV}/bin/pip" install -r <(./pants dependencies :: |
  xargs ./pants filter --target-type=python_requirement |
  xargs ./pants peek |
  jq -r '.[]["requirements"][]')

Note that this requires installing the tool jq.)

Again, this only works if a single consistent global resolve is possible for your repo. If not, you'll have to segment the set of requirements appropriately (e.g. ./pants dependencies --transitive path/to/some/project::), generate multiple virtualenvs, and set up separate IDE modules for each.

Generated code

If you're using Protobuf and gRPC, you may want your editor to be able to index and navigate the generated source code.

Normally Pants treats generated code as an internal byproduct, and doesn't expose it. But you can run the export-codegen goal to generate code to a well-known output location for consumption:

shell

$ ./pants export-codegen ::

The generated code will be written to dist/codegen, and you can now add them as sources in the IDE. For example, in PyCharm you would mark dist/codegen as a "Sources" folder.

Warning: you will have to manually rerun this goal when changes are made.

Remote debugging

You can use PyCharm to debug code running under Pants.

See the following links for instructions on how to do so under the test goal and under the run goal.

IDE integrations

We have not yet developed tight IDE integrations, such as a PyCharm plugin or a VSCode extension, that would allow the IDE to run Pants on your behalf. If you're interested in developing this functionality for your favorite IDE, let us know!