https://pantsbuild.org/ logo
Join Slack
Powered by
Is it possible or reasonable to have BUILD files i...
# general
f
Is it possible or reasonable to have BUILD files in directories other than the ones they describe? Like to have some remapping of BUILD files to other paths? This could be used e.g. to maintain a shadow directory of BUILD metadata. Something like where 
.build/src/module/BUILD
would map to 
src/module/BUILD
?
h
I don't think I understand the motivation - what's the value of a shadow directory?
f
"centralized" management of pants-related things
👍 1
I don't think this is possible currently... there seems to be a pretty strong notion of... a target's address comes from the location of the BUILD file it is defined in
➕ 1
h
Yeah, not possible currently. A target can only "own" source files in the current dir or subdirectory
In the meantime, the best workaround is probably to use a single BUILD file at the root of your project with 
**
recursive globs. We don't generally recommend that per https://www.pantsbuild.org/docs/targets#target-generation, but it is totally feasible to do especially thanks to the 
overrides
field added in 2.8 (If you haven't read that page in the past two months, I encourage re-reading it. It was rewritten with some conceptual changes in 2.8)
👍🏻 1
f
Hmm, that could work, just a handful of BUILD files isn't gonna bother anyone
h
I think it's theoretically possible to have a single BUILD file for the whole project even. (Unless you're using Go)
f
agree that it's not idea, but yeah even tailor doesn't seem to mind, as long as the sources are contained in some build file, it doesn't care
👍 1
how do you reference a file as a dependency if you do that in another target though? Just putting 
path/to/file.py
in the 
dependencies
field of another target gives
Copy code
❯ ./pants dependencies src:alerting-config-ci
14:23:36.92 [ERROR] 1 Exception encountered:

  ResolveError: Directory 'path/to' does not contain any BUILD files.
nvm found it, needed 
path/to/file.py:../../all-sources
(where `all-sources) was the name of my recursive target
➕ 1
your docs are really good... there's just a lot to read 🙈
❤️ 1
h
Thanks! And yeah agreed with a lot to read. I've realized how important it is to keep simplifying things so that you can intuit stuff - we can't assume people actually read docs, especially because Pants is used by every single engineer and not just 1-2 power users
Fyi we were considering last year replacing "file address" syntax with "generated target" syntax. 
dir:tgt#app.py
rather than 
dir/app.py:tgt
. A benefit would be that 
path/to/file.py:../../all-sources
becomes 
//:all_sources#path/to/file.py
withou the 
../
part. But we decided file address syntax is generally better, and it's part of why we recommend 1-1-1 to avoid the awkwardness of 
../
f
might be for the best
h
Which part might be for the best?
f
not having the other syntax... I kinda agree with the design decision to encourage 1-1-1
👍 1
h
Technically this is the additional syntax -- we always have "generator" syntax for non-file-based targets, like in 2.10+ 
python_requirements
will generate 
3rdparty/python#Django
instead of 
3rdparty/python:Django
. So we'll have 3 syntaxes: • normal one for explicit targets • file addresses • generated targets I still think it's useful to consolidate to just two syntaxes (https://github.com/pantsbuild/pants/issues/12917). But I wasn't persuasive enough and I see benefits to file addresses
f
oh, so generated target syntax exists?
h
Yep, and it must because there are file-less targets. It's used by `pex_binaries, 
python_requirements
, 
go_thirdparty_package
(already released)
f
ah, but it doesn't seem to work now for these generated file targets
h
Yeah, generated file targets only use file address syntax. I'm proposing in #12917 that we change it so every generated target uses the 
#
syntax regardless of it describes files or is file-less. Consistency is valuable
🤔 1
f
Just off-hand though, adding 
#
to things I might type on the command line doesn't sound great
I think shells differ on how they handle that too
or maybe I'm wrong
h
I think the shell can handle it:
Copy code
❯ ./pants list 3rdparty/python#PyYAML
3rdparty/python#PyYAML
adding # to things I might type on the command line doesn't sound great
You normally would not need to because you can use file arguments like 
f.py
. Pants will find the owning target for you
👍🏻 1
A major downside Stu has pointed out though is that the output of things like 
./pants test
would be less useful and less copy-and-pasteable. We would report that 
dir#tests.py
succeeded, rather than 
dir/tests.py
4 Views
Open in Slack
PreviousNext
Powered by