Hmm, that could work, just a handful of BUILD files isn't gonna bother anyone

I think it's theoretically possible to have a single BUILD file for the whole project even. (Unless you're using Go)

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

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

❯ ./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

your docs are really good... there's just a lot to read 🙈

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

../

might be for the best

Which part might be for the best?

not having the other syntax... I kinda agree with the design decision to encourage 1-1-1

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

Are there any plans for integrated C/C++ support in the future? I use CMake for everything, but so many of my projects are C++ and Python (for testing, or bindings), so it would be nice to use the same runner. My current workarounds are to use the shell target to kick off cmakebuild, or Docker whenever this is ready: https://github.com/pantsbuild/pants/issues/13682

oh, so generated target syntax exists?

Yep, and it must because there are file-less targets. It's used by `pex_binaries,

python_requirements

,

go_thirdparty_package

(already released)

ah, but it doesn't seem to work now for these generated file targets

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

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

I think the shell can handle it:

❯ ./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

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

Hi Pants team and users. Been working with Pants for a week or so now to bring a decently sized monorepo into a more scalable place. We started with Bazel and found it far too prohibitive to work at this time. Pants has been much better and the docs are much easier to follow! I did have one small question about

export-codegen

(I'm working with protobufs). I can happily generate code for cases where I point to a specific target (e.g.

./pants export-codegen some/path

) but I was wondering how I can generate everything under a certain subdirectory. I've seen

./pants export-codegen ::

for everything in the workspace, but I was hoping to go more incrementally as I update paths and such to get things working.

Is it possible to override an individual docker build arg at package time?

New section of the home page! "Why Pants...." A related question, for you the user:

I've got a bit of a harder question today: For background, we're working with NASA's GMAT R2020a software. They have exposed a python API (although in a rather non-standard way) that we have been using fine with our previous venv/setup.py traditional way of managing python. When transitioning over to Pants, something inside their library has broken. The C++ calls that work fine outside of Pants are now showing segmentation faults. I know I've included everything with the

files

target so that the software distribution is available in the sandbox. I've checked this by running the

dependencies

goal and by running a

diff -r

on what was passed to the sandbox and what I have on disk and only saw differences in

__pycache__

folders. So, I think my question is more just looking for general guidance on what might be different about the two execution environments. It's a prebuilt distribution so it should have everything it needs but does rely on some system libraries (e.g.

libpng12.so

). Is it possible that these aren't discoverable when running in the sandbox environment?

I have some questions about configuring pants tailor. First: We're running an ancient version of pants V1 and I need to keep those build files intact for now. How do I set up tailor to read from/write to a filename other than BUILD? Second: We have a directory full of scripts that are not managed by pants. Tailor is currently failing because some of those scripts behave badly. I have the following in my pants.toml but it doesn't appear to be helping. What am I missing?

[tailor]
ignore_paths = ["/scripts"]
ignore_adding_targets = ["/scripts/**"]

hey folks! thanks so much for your votes so far. if you haven’t voted yet (we’ve switched from idea gathering to voting!), please take a few minutes to get your voice heard for our 2022 priorities! https://pantsbuild.slack.com/archives/C18RRR4JK/p1642626085023200

this is not a direct pants question, so please let me know if there's a different channel I should post in, but based on slack searches it looks like there may be others with a similar use case using pants that I'd like feedback from if possible! I'm trying to use pants to generate a PEX that's compatible to be used as a packaged pyspark environment, specifically to be run on gcp dataproc. I posted my question to stackoverflow yesterday, but in the meantime - has anyone had luck with this? maybe @freezing-vegetable-92896 or @dazzling-diamond-4749, who I see had comments referring to spark a few months ago