brash-iron-24542
04/27/2023, 5:16 PM./pants tailor ::
, it creates BUILD
files in unexpected locations. If I have a python project at src/apps/foo
, I would expect the file to be at src/apps/foo/BUILD
, but instead, it puts it in my module at src/apps/foo/foo/BUILD
.sparse-lifeguard-95737
04/27/2023, 5:18 PMsrc/apps/foo/foo/
an existing directory containing python source files?brash-iron-24542
04/27/2023, 5:18 PMsparse-lifeguard-95737
04/27/2023, 5:19 PMtailor
will create a BUILD
file in every directory with Python code. the auto-generated targets will cover just the files in that dir (not recursive)BUILD
in the root that recursively covers all your sources, but you have to manually write itbrash-iron-24542
04/27/2023, 5:20 PMsparse-lifeguard-95737
04/27/2023, 5:31 PMbrash-iron-24542
04/27/2023, 5:35 PM/project-name/project_name/__init__.py
. With all my other random stuff in /project-name/.
TBF, I am coming from a background that doesn’t use a monorepo, so this is all new to me.sparse-lifeguard-95737
04/27/2023, 5:38 PMpants.toml
is (as far as I can think of right now) the only file whose location matters. it would typically be in the root of your monorepo (not one per project, in the root of the project)pants.toml
you’ll define your source roots. these typically line up with the entries you’d used to set on PYTHONPATH
(i.e. in my repo we used to set PYTHONPATH=src
in our “set environment” script. now we have /src
as a source root in pants.toml
)BUILD
files doesn’t matter to pants
. any time you run pants
, it looks under your source roots for BUILD
files, then looks inside the files at the targets (and at the `source`/`sources` fields set on those targets)BUILD
files does matter when you’re trying to create explicit dependencies
between targets. the default of one-BUILD-per-dir lets you do things like:
dependenices=[
"//path/to/your/dir/file.py"
]
if you put a BUILD in a root dir with sources=["**/*"]
the explicit references can get messier, like:
dependencies=[
"//path/to/your/dir/file.py:../../../source-target-name"
]
brash-iron-24542
04/27/2023, 5:45 PMsparse-lifeguard-95737
04/27/2023, 5:45 PMPYTHONPATH
is affected only by source roots, not by BUILD
file placementbrash-iron-24542
04/27/2023, 5:47 PMsparse-lifeguard-95737
04/27/2023, 5:47 PMtailor
will create python_requirements
targets for you toobrash-iron-24542
04/27/2023, 5:48 PMsparse-lifeguard-95737
04/27/2023, 5:50 PMpython_requirements
is a “generator” target (kinda like a macro) that reads your requirements.txt
content on-the-fly and produces individual python_requirement
targetspython_sources
generates a python_source
target for every Python file you have in a directoryrequirements.txt
entries into individual python_requirement
targets
• keep your `requirements.txt`s and use python_requirements
I personally do the 2nd option because it’s more friendly to other tooling in the space (i.e. dependabot)brash-iron-24542
04/27/2023, 5:53 PMpython_requirement
in the project’s BUILD
instead?sparse-lifeguard-95737
04/27/2023, 5:54 PMbrash-iron-24542
04/27/2023, 5:54 PMsparse-lifeguard-95737
04/27/2023, 5:55 PMpython_requirement
. let me whip up an examplebrash-iron-24542
04/27/2023, 5:55 PMpython_library
target, but that seems to be deprecated from what I can tellsparse-lifeguard-95737
04/27/2023, 5:56 PM/
pyproject.toml
projects/
project1/
__init__.py
main.py
libs/
__init__.py
lib1/
__init__.py
util.py
lib2/
__init__.py
util.py
in pyproject.toml
you could have:
[source]
root_patterns = [
"/projects",
"/libs",
]
with that in place, you could run pants tailor
to generate BUILD
files. by default it will generate:
• projects/project1/BUILD
• libs/lib1/BUILD
• libs/lib2/BUILD
the content of each BUILD
file will be identical boilerplate:
python_sources()
with all of that in place, you’ll be able to import between the various python files. i.e. you could write the following in `projects/project1/main.py`:
import lib1.util
import lib2.util
import
a module in a file covered by python_sources
, Pants will compare that module path against all the other python_sources
in the repo and see if it can find a match. the matching runs relative to source roots (which is why lib1.util
would match to libs/lib1/util.py
, because /libs
is declared as a source root)brash-iron-24542
04/27/2023, 6:05 PMsparse-lifeguard-95737
04/27/2023, 6:08 PMdocker_image
targets can infer dependencies on pex_binary
targets, but not raw `python_source`s (at least not yet)tailor
all your python_source
targets
2. create a pex_binary
target per “entry point” in your monorepo, pointing at the relevant main.py
3. write a Dockerfile
that `COPY`s the pex_binary
into your image, instead of copying in all the raw sources
4. tailor
or manually write a docker_image
target covering your Dockerfile
brash-iron-24542
04/27/2023, 6:11 PMPYTHONPATH
?sparse-lifeguard-95737
04/27/2023, 6:14 PMbrash-iron-24542
04/27/2023, 6:19 PMsparse-lifeguard-95737
04/27/2023, 6:22 PMpex_binary
target produces a zipapp archive. that archive extracts itself on first run to a content-addressed directory, so it can be tough to find the files in the running containerbrash-iron-24542
04/27/2023, 6:28 PMsparse-lifeguard-95737
04/27/2023, 6:30 PMbrash-iron-24542
04/27/2023, 6:32 PMsparse-lifeguard-95737
04/27/2023, 6:34 PMbrash-iron-24542
04/27/2023, 6:35 PMbreezy-mouse-20493
04/27/2023, 9:23 PMhappy-kitchen-89482
04/29/2023, 1:17 AM