My org is considering using

BUILD.pants

for all of our build files. Renaming existing ones was easy, but I noticed

./pants tailor

was still creating

BUILD

files even with

build_patterns = ["BUILD.pants"]

(i think this option doesn't actually change anything, but was trying to be explicit). I went looking at the code and found the ability to change this was recently added in https://github.com/pantsbuild/pants/pull/12979. I'm currently running

2.7.0

, am I correct that this option won't be usable until

2.8.0

? I tried

2.8.0.dev0

and it still isn't available. And I assume I don't want to be using the beta..

Hello! That's correct it isn't usable until 2.8. The latest dev release was 2.8.0.dev3, so that should include the new feature We're hoping/planning to put up the first release candidate either this week or next, so it's close-ish to being stable If you don't want to rely on it in production, you could maybe temporarily use 2.8.0.dev3 to run

./pants tailor

, then downgrade to 2.7

Thanks Eric. I just saw dev3 in the git tags and can confirm that works with

[tailor]\nbuild_file_name = "BUILD.pants"

. I thought not changing the toml and using

./pants tailor --build-file-name BUILD.pants

would work, but did not for some reason

I thought not changing the toml and using 

./pants tailor --build-file-name BUILD.pants

 would work, but did not for some reason

that should work… all options should be able to be specified in any of env, config, cli. odd.

Oh,

./pants tailor --build-file-name=BUILD.pants

with an

=

, yikes

should work either way though? if the option requires an argument, it expects it

However even for reading BUILD files build_patterns = ["BUILD.pants"] seems unnecessary because by default it will look for any BUILD.{suffix} anyway.

Yeah, not necessary. But would make it explicit and avoid the risk of users accidentally checking in

BUILD

while I was hopeful (before I found tailor] build_file_name ) that [GLOBAL] build_patterns might magically apply to tailor,

FYI we couldn't do that because it's not clear how to map a pattern like

BUILD.*

with a glob into the file name to use

thanks!

Hey @eager-dress-66405 would you be interested in contributing a PR that improves the docs for these two options to reference each other? It's nothing more than updating these two places https://github.com/pantsbuild/pants/blob/e190c287ef36bf3a40194e0dbdd85ab4bc85057a/src/python/pants/option/global_options.py#L1351-L1361 https://github.com/pantsbuild/pants/blob/e190c287ef36bf3a40194e0dbdd85ab4bc85057a/src/python/pants/core/goals/tailor.py#L255

Can do! Will be a good first dip into the codebase

Sweet, thanks Michael! Check out https://www.pantsbuild.org/docs/contributor-overview for our contributor guide Tip: you can probably get away without running

./pants

and the

pre-commit

hooks. Compiling Rust is really really slow the first time, unfortunately. Because this change is fairly simple, it's fine to not test locally and let CI do that for you Two FYIs with getting the

help

string to play nicely with terminal sizes, btw: 1. We use implicit string concatenation, like this, because it lets the terminal resize rather than forcing newlines at certain widths

help=(
   "hello world this is "
   "a single sentence"
)

1. We use

\n\n

to start a new "paragraph". Makes it easier to scan docs. What you're adding doesn't relate to what's already there, so should probably be a new paragraph