https://pantsbuild.org/ logo
#general
Title
# general
l

lively-dusk-46231

10/22/2022, 8:40 AM
H, I am trying out pants for the first time. I have a python project where I have the current structure as:
Copy code
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
1
I am trying it currently with:
Copy code
[source]
marker_filenames = ["setup.py"]
h

high-magician-46188

10/22/2022, 9:05 AM
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.
l

lively-dusk-46231

10/22/2022, 9:21 AM
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.
You're right - I am currently just trying to see what I can do with
pants
so I am not looking to move from whl -> pex and so on. Just trying to understand if I can install/lint/format/test/run with pants and what benefits it gives
👍 1
Question question though - should I be removing
setup.py
,
setup.cfg
,
pyproject.toml
(and other black, isort configs etc) And be providing them in the
BUILD
file ? Cause all these files seem to be capturing metadata/configs about my code
h

high-magician-46188

10/22/2022, 9:26 AM
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).
h

happy-kitchen-89482

10/22/2022, 1:11 PM
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).
We also want to move towards “inheriting” metadata up the filesystem hierarchy, so that you can add a local BUILD target without having to exclude those source files from the higher-up BUILD target.
So it’s definitely possible that we should change how tailor works to allow generating one BUILD file per source root, or per project, or something like that.
For now, you can achieve this manually by writing the small number of BUILD files (again, remembering an explicit
sources=['**/*.py', '!**/*_test.py']
, see https://www.pantsbuild.org/docs/targets#source-and-sources-field)
Or, if your tests are in separate dirs from your sources, your
sources=
can be simpler
b

bitter-ability-32190

10/22/2022, 1:14 PM
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
l

lively-dusk-46231

10/22/2022, 1:31 PM
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.
One of the thing that really threw me off was the recommendation that
pants tailor --tailor-check
should run in my CI. So I assumed that what tailor is doing is the thing I should be following and even keep a CI check for
b

bitter-ability-32190

10/22/2022, 1:34 PM
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)
l

lively-dusk-46231

10/22/2022, 1:40 PM
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
🎉 1
2 Views