H, I am trying out pants for the first time. I have a python project where I have the current structure as:

projects/
    my_api
        my_api
           web
           schema
           service
        my_api_test
        setup.py
    ... 2 others
libs/
    ... 5 common libraries which are used across the projects

And when I run

./pants tailor

it seems to be creating a BUILD file for every single folder (100+) in

my_api

,

my_api.web

,

my_api.schema

,

my_api_test

, etc. Is that expected ? I was thinking I just needed 5 (libs) + 3 (projects) BUILD files

Hi, I’m still trying out pants as well and I had a similar post a bit back. I think it mainly depends on what is your previous setup and that in some cases

tailor

produces a good result, and in others a lesser one. I’ve described the solution for my use-case here: https://pantsbuild.slack.com/archives/C046T6T9U/p1666426822534479?thread_ts=1664982667.688279&cid=C046T6T9U. For your case, I imagine that the bast case would be to delete this

BUILD

files you think are unimportant, review those who left. I also think that it depends on the progress you have on the adoption ladder. That is, if you only want pants to produce Wheels for now and defer the whole Pex story for later, then a single BUILD file per package should be enough (and maybe another global one at the root). Please note that I’m myself not too knowledgable on the matter and that the core team might be able to help you use tailor correctly.

Hmm, I see. I guess the assumption I was making was that

pants tailor

has created the "recommended" way to generate this. But I now realize it is not the smartest and I can use my code understanding to make this simpler Thanks! Let me try that out.

I think that: 1. The

pyproject.toml

should be kept as-is. 2. The

setup.py

could be ignored by adding

generate_setup_default = true

under the

[setup-py-generation]

in the

pants.toml

file. 3. I’m not sure about the

setup.cfg

, as I’ve never used it (we didn’t had it at all in the first place).

Hi! Sorry for the confusion. There is a slight recommendation to have one BUILD file per directory, so that metadata can live close to the code it describes. So that’s why tailor generates simple BUILD files in every dir that has source files - when you want to modify the metadata for a source file (say, add a timeout for a test), you already have the BUILD target available. Now, however, Pants has

overrides

, that allow you to set metadata on only specific files owned by a BUILD file target (see https://www.pantsbuild.org/docs/targets#target-generation). So there is less reason to have all those BUILD files, and it may make sense to have just a few high-up ones, at least at first, whose sources glob over everything underneath them (the default

sources=

only glob over files in the same dir).

I think the challenge we have right now, is how you refer to files in a

dependencies

field is difficult and unintuitive when you do the "big glob" approach. A while back I think we agreed on wanting to address that, but haven't yet

Makes sense @happy-kitchen-89482 Once I understood that I can control the BUILD and as Tal mentioned it's not forced to be generated, I could go through python_source/python_sources documentation and create a build file pretty easily within 30mins.

That recommendation is if you want to ensure all relevant files are made known to pants. Which can be really useful if you want to ensure all your code is formatted/linted/checked/etc... (E.g. we have a copyright checker implemented on top of pants. So making sure every file is known to pants help give us confidence we're not missing any headers)

Yep. Makes sense. The thing I did not realise was that if I use

sources=['***/*.py']

Then tailor will not try to auto generate build files for lower level folders :) That is very helpful and makes sense So now with my manually crafted BUILD files I can enable tailor in CI without any issue