The common pants way to do things is to put `BUILD...
# general
h
The common pants way to do things is to put
BUILD
files in all directories. Is there any way to make a
python_distribution
that does something like
src/my_project::
in the
dependencies
section? Am I forced to make a
pyproject.toml
to do that specifying?
h
Like, depend on everything in that glob? The dist pulls in transitive deps, so typically you only need to add one or two direct dependencies
h
I originally tried something like
Copy code
resources(name="my_source_files", sources=["//where/my/stuff/is/**/*.py"])
and then put that in the
dependencies
section of my
python_distribution
. It definitely didn't grab all the proper dependencies so I'm wondering if I can point directly to the
python_sources
defined throughout that root directory instead of making this separate
resources
target.
It got a lot of the transitive dependencies, but wasn't perfect.
h
There is currently no support for globs with addresses. For a long time, a concern was that the address syntax is already really complex and I would be scared to add even more. Someone had the idea of adding a dedicated field for globs, which removes that concern. So I could see us wanting to add it In the meantime, you unfortunately must manually enumerate. If you need to use that list multiple times, you can use the generic target target https://www.pantsbuild.org/docs/reference-target
h
It's a large enumeration to go through and capture all the relevant
python_sources
😞
I'm really curious how this is ideally supposed to work since the recommendation is to disperse
BUILD
files.
I found a way around it. I think the original incomplete dependency collecting was because I was depending on a
resources
target.
🙌 1
e
A good rule of thumb is if the target is a
file
or
resource
then Pants is dumb and you have to tell it everything. If the target is a
*_source
Pants is smart and can infer dependencies, etc. So for the latter you generally just need to point at the "root" target if there is a natural one and then dependency inference will do the rest except for those hopefully rare cases where you had to add a manual dependency.
âž• 1
h
Yeah, totally agree about
resources
not doing anything fancy transitively. My issue is that, say I have a project like
Copy code
-> src
  -> lib1
    - BUILD.pants
    - lib1_module1.py
    - lib1_module2.py
  -> lib2
    - BUILD.pants
    - lib2_module1.py
    - lib2_module2.py
  -> lib3
    - BUILD.pants
    - lib3_module1.py
    - lib3_module2.py
, how is is it recommended to make a distribution? It seems like I have to do something like
Copy code
python_distribution(
  dependencies=[
    "src/lib1:lib1",
    "src/lib2:lib2",
    "src/lib3:lib3"
  ]
)
if I am to follow the Pants convention of putting BUILD files throughout the source tree. The way I get around this is moving my
python_sources
target up to the top of
src
and changing the glob pattern to
***/**.py
. Then, I don't have to update my
python_distribution
dependencies every time I add a new lib to that source tree.
e
Aha. Is this an internal only distribution? In general public distributions just have 1 root package; so you don't have this issue.
h
Yeah, internal for right now