I think lockfiles are what you're after https://www.pantsbuild.org/docs/python-third-party-dependencies#lockfiles

Or rather, they might satisfy the usual reasons for listing transitive dependencies, like being able to pin their versions or enumerate them

What you're looking for is this option: https://www.pantsbuild.org/docs/reference-python-infer#unowned_dependency_behavior

Set it to

error

, if any

import

doesn't match a firstparty or top-level thirdparty Pants'll error

(This is the exact case I added this feature 😛 )

Great! Thank you 🙂

i have a

pex_binary

(with

execution_mode="venv"

) thats running fine. but sometimes, without a code change it fails importing modules. if i delete all caches (

~/pex

&

~/.cache/pants

) it works again. sometimes multiple times, sometimes only a first time. tested versions: 2.14.0rc0, 2.14.0.rc2, 2.15.0.dev3 tested layouts: loose, packed, zippapp

Another Q: Does Pants support PEP 420 – Implicit Namespace Packages?

I get a lot of warnings of the form:

16:51:26.87 [WARN] Pants cannot infer owners for the following imports in the target proj_1/test/foo.py:

  * numpy (line: 2)

Also with

click

and other packages. These packages are all in the req file. What does it mean to own them in that case?

🧵

“owning” means “a target that provides them” - that message could be clearer, sorry

But as you say, these are provided by the requirements file

What does that file’s python_requirements look like?

It doesn’t have one. I think?…

grep python_requirements -r .

returns no results.

I think that while

pants tailor ::

saved me a lot of work, it also got me to be dependent on it and to not understand the system. As far as I can tell, the

BUILD

files are temp files that are not really required due to 2 reasons: 1. They are auto-generated by the

pants tailor ::

command. 2. There are hundreds of them, it is not rational to maintain so many config files.

By reading https://www.pantsbuild.org/docs/targets I don’t really get in what cases I need a

BUILD

file. Also, after running

pants tailor ::

and

cat **/BUILD

I get something along the lines of:

...

python_sources()
python_sources()
python_sources()
...
python_sources()

python_test_utils(
    name="test_utils",
)

python_tests(
    name="tests",
)
python_tests(
    name="tests",
)
...
python_tests(
    name="tests",
)
python_tests(
    name="tests",
)
python_tests(
    name="tests",
)
python_tests(
    name="tests",
)
python_sources()
python_sources()
python_sources()
python_sources()
python_sources()
python_sources()
python_sources()
python_sources()
python_sources()
python_sources()
python_sources()
python_sources()
python_sources()
python_sources()
python_sources()
python_sources()
...

when that page says “targets are metadata”, what they mean is that they have a bunch of fields which you can set: see the help for

python_tests

for example: https://www.pantsbuild.org/docs/reference-python_tests

extra_env_vars

,

timeout

,

tags

,

resolve

, etc are frequently set

but when dependency inference fails, you might also need to explicitly add some

dependencies

in any case: if

numpy

is declared in a

requirements.txt

, and that file doesn’t have an owning target, then it won’t be loaded: you’ll need to include it in what gets tailored

So you do need a (tailored or handwritten) python_requirements() target to own your pants-requirements.txt: https://www.pantsbuild.org/docs/reference-python_requirements

Unclear why tailor didn’t create one, I thought it recognized *-requirements.txt as a requirements file

but anyway, you can add one manually

More generally, as Stu said, think of targets in BUILD files as a way of saying to Pants “here is some metadata about the code in this dir”. In many cases (e.g., all those

python_sources()

) the metadata is empty. And I get that this is annoying. The reason tailor creates those is that in the past they were necessary. And we still find them to be useful in practice, because they are an obvious place to add metadata when you need to. But - you could replace them with a smaller number of higher-level

python_sources()

with recursive globs over their subdirs, if you wanted to. Tailor is smart enough to not try to regenerate for files that are already owned by some higher-up target.

But note that the BUILD files, whether you have few higher-up ones or many lower-down ones, do need to be checked in. Tailor creates initial ones, but you then manually update them as you need to add metadata. So tailor is to help you get set up, and you can run it periodically as you add new dirs, new tests, new binaries, etc.

I hear you that “lots of nearly-empty BUILD files” is not a great first impression, and it would not be hard to improve this at least somewhat

Thanks, I’ll do some more reading and experiments and will report back. (prob. won’t be today)

Hi folks - periodic reminder that you can support the Pants project by: • starring it at https://github.com/pantsbuild/pants • encouraging your teammates to star it • adding your company here: https://www.pantsbuild.org/page/who-uses-pants And we’d really appreciate it if you did! It helps grow the community, which in turn helps us all.

Lambda function bundles generated with

python_awslambda()

are pretty heavy as they embed PEX and wrapping code. Is there an easy way to not use PEX and simply add the project's source code and its dependencies?