I'm seeing a weird probably-bug after adding a

files(name = "all-the-files", sources = ["**"])

target to the repo root (don't ask me why simple smile). I'm guessing it's because we have some paths in the repository that contain asterisk (don't ask me why simple smile).

InvalidFieldException: The 'source' field in target //some/project/data/[*]/_SUCCESS:../../../../../all-the-files should not include `*` globs, but was set to some/project/data/[*]/_SUCCESS. Instead, use a literal file path (relative to the BUILD file).

The actual path is

some/project/data/*/_SUCCESS

.

you can set something like this:

[GLOBAL]
pants_ignore.add = ["some/project/data/*"]

I'm not surprised that Pants is upset with a file path with

*

embedded in it

That's a good unblocker for now. Although eventually this might pose a problem for adoption and might not be what the team intended so just LYK.

Mind sharing the use case for

*

in a file path?

I'd have to hunt down the codeowners and ask them 😉. Which I might eventually do but maybe not out of the blue before the build system gains actual traction around here.

Okay - if you're motivated enough, I suspect it's plausible to make the codecheck more robust to allow

*

to work. Maybe something like escaping it. (We still want to error generally for

*

because it's a core assumption that a

file

target respond to exactly 1 file) This is the error you're hitting: https://github.com/pantsbuild/pants/blob/08410e5b94d3e3aa86b2538ee1991d964e27e72c/src/python/pants/engine/target.py#L2184-L2193

Oh I see. This is kind of a fail-fast to prevent accidental use of globs where paths are required

Oh I see. This is kind of a fail-fast to prevent accidental use of globs where paths are required

Exactly

Not too familiar with the architecture but would it be possible to check whether the file actually exists before making that assertion

Yeah, although there's more complexity here that the Rust engine will interpret

*

as a glob to match everything in that directory. Which is not the semantics you're looking for here -- you want

*

to be interpreted as a literal character Which is where I think escaping is relevant, figuring out how you can escape

*

so that the engine treats it as a literal and not a glob

Yeah it seems like the standard

\

escape is what you'd use in a glob engine. At least based on the fact

echo **/\*/**

works as I'd expect on my shell.

you could experiment quickly with this by using

./pants count-loc '<path>'

, where the

''

is to avoid shell escaping from happening. That will have the Rust engine's glob semantics kick in. Maybe set up something like this:

dir/
dir/a.txt
dir/b.txt
dir/*/
dir/*/a.txt
dir/*/b.txt

experiment with how quoting gets different results

Hmm so you're suggesting that the user would e.g. do

file(source="my/asterisk/\*/path")

instead of

file(source="my/asterisk/*/path")

?

yeah, but I'm not sure what the escape is in this case

And similarly

files

would expand out globs into the escaped paths rather than the literal result of the glob expansion

which it may already be doing? from top of the thread

some/project/data/[*]/_SUCCESS

No the macro (?) seems to add that itself. Yeah wondering why that's being used rather than

\