🧵

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

What does that file’s python_requirements look like?

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()
...

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

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

For the record, the solution that worked for me was: 1. Remove the artifacts produced by

pants tailor ::

2. Re-reading all of the docs under “Getting Started”, “Python”, “Writing Plugins” and a bit more. 3. Implement my own script to produce a global

requirements.txt

for Pants. 4. Implement my own script to produce

BUILD

files for Pants. I now have a much better understanding (and progress). My takeaway here for me is that the docs are helpful (in contrast to the usual stuff), so if you have a special use-case (like that fact that we have our own custom build-system that is not well supported by

tailor

), you should probably just trudge through it.