https://pantsbuild.org/ logo
Join Slack
Powered by
Small bit of feedback on file arguments: we freque...
# general
w
Small bit of feedback on file arguments: we frequently keep README files next to the code in our repos for documentation / runbooking etc. Recently ran into a build issue where changing a readme triggered a . failure:
Copy code
Please check that there is a BUILD file in `src/media_processing/xcoder_audio_levels` with a target whose `sources` field includes `src/media_processing/xcoder_audio_levels/README.md`. See <https://www.pantsbuild.org/build_files.html>.
Naturally, these files do not belong to a target since they are not runtime artifacts. If there is an option to safely ignore 'orphaned' files, consider including that in the error message. If there isn't would like to kindly request one as building a good exclustion list can become quite cumbersome
đź‘Ť 1
w
there is!
but yes, good point.
Copy code
--owners-not-found-behavior=<OwnersNotFoundBehavior> (default: error)
What to do when file arguments do not have any owning target. This happens when there are no targets whose `sources` fields include the file argument.
for automated cases you’ll probably want 
--owners-not-found-behavior=ignore
w
ah thank you
w
i’ll follow up on adding the option to the error message though: thanks!
w
thank you! if you don't mind me asking, what's the justification for the 
error
default? it seems like especially for newer features where an ignore would not be dangerous that 
warn
is more appropriate as users could be nudged without encountering errors unexpectedly
for . example, we had been using file args in our build successfully for a few days until we hit a changed file without a build owner
w
sorry for the trouble.
w
oh no worries at all1
just thought i'd ask the question
w
the reason in this case is that this unified two features: 
--owner-of
, which people sometimes used manually, but which was mostly used in automation, with CLI “specs” (which used to only be targets)
when users specify targets on the CLI, they want to know if they don’t exist… likewise, we felt it was important that if a user specified a file or file glob on the CLI, they would see an error if it didn’t exist or wasn’t owned*
but in automated cases “not owned” is a non-issue (…not existing might be an issue!)
w
ah understood
thanks for the context
a
please continue to ask questions like this — very important to not let us get complacent about breaking users!
h
@witty-crayon-22786 would 
--pants-ignore
be relevant too? You could add 
**/README.md
to it, although that would mean you could never add that file to the 
sources
of a target, which could be an issue
a
could we allow explicit sources (i.e. not globs) to override a pants ignore setting?
w
@hundreds-father-404: the bit of context that i was assuming here is that this is related to the 
--spec-file
question from the other day. is that right @wonderful-iron-54019 ?
@hundreds-father-404: but… no, i don’t think it’s relevant actually. ignoring the file would switch that particular error from a “no owners for file” to “file didn’t exist”
đź‘Ť 1
w
yes correct
we switched to spec-files b/c didn't want . our changes . to .accomodate the 
globs
deprecations to trigger a system wide redeploy, so we were grepping . out the BUILD files
đź‘Ť 2
h
Makes sense. I think erroring will still be the right behavior because of the risk of warnings getting lost in scripts and CI, so long as the error message is improved to explain 
--owners-not-found-behavior
.
đź‘Ť 1
w
6 Views
Open in Slack
PreviousNext
Powered by