Bike shed opportunity - feedback welcomed! We're adding proper "target generation", which allows for us to fix a lot of issues with the old "macros" we have (

python_requirements

,

poetry_requirements

), and unlocks new boilerplate reduction. We need a syntax for how to address generated targets, e.g. in the

dependencies

field. It needs to include the generating target's address so we know how to generate it. The current proposal is

dir:generator!generated

, e.g.

//:reqs!Django

or

src/py/project:lib!foo.py

. But,

!

requires quotes to work in the terminal 🤷 The other alternatives to

!

are

=

and `@`:

When, why, how often would you type these in the terminal?

Hopefully you would not type frequently in the terminal. You should use file and directory paths for the most part But two times it's necessary to use an address in the terminal: 1) You have a generated target that is file-less, like you want to run

./pants dependees //:reqs!Django

(a

python_requirement_library

), so you can't use a file argument 2) You have >1 target owning a file, like two

python_tests

targets called

:tests_py2

and

:tests_py3

that run the same tests but w/ different interpreters. You only want to run one - you need to use the address

#

or

$

?

!

definitely sounds dangerous given commandline issues

I like

#

and

$

more than

=

and

@

! Thanks. (We don't currently ban those when used in target names, so it's not technically safe to start using...but we could maybe retcon it with a good error message and communication to community.)

It seems a little off that the generator gets front billing.

//:Django

is what I know as a user IIUC and then

//:Django@reqs

is what I need due to Pantsisms (do I really need it if there is just one applicable generator?

if there is just one applicable generator?

That's going to be rare if https://docs.google.com/document/d/1HpJn2jTWf5sKob6zhe4SqHZ7KWBlX4a6OJOwnuw-IHo/edit# is accepted. Anytime you have

python_tests

or

python_library

, that's a generator. And it's possible to generate in a subdirectory, so we would have to look up the whole source tree for candidate generators

$

is also problematic on shells (at least bash+zsh) as that is a var reference.

Oh good point Jacob, I didn't think about writing Bash scripts that need to use addresses.

$

is indeed a bad idea there Cool, I like

#

! (still open to further input, of course!)

I do like

Django@3rdparty/python:reqs

now that I think of it

So, that would be

foo.py@src/py/project:lib

, and

subdir/f.py@src/py/project:lib

. I like the Django example, but not sure how I feel about those last two examples?

Throwing in my 2 cents.. I think that as the generated target can be seen as a “member of the set of targets from generator”, that ∈ would be the most accurate, i.e.

foo.py∈src/py/project:lib

but that is a pain to type (and also doesn’t really stand out), so not really viable. Next up,

@

, I think to use the at-symbol, we ought to respect the order of

element@parent

to not confuse things too much, granted, it makes things look weird, given that it is not the order of

path/to:target

so is a bad choice for that reason, which would be more conformant if it were

foo.py@target:path/to

. I agree with the notion of avoiding symbols with a special meaning when used unquoted in a shell, even if rarely used, to avoid mistakes (and forcing the use of quotes). If it wasn’t for that, I kind of like

!

for its notion of being something “exceptional”. I like the

#

as a way to further decompose the

target

so

path/to:target#foo.py

make sense to me. It also stands out well. I had another symbol in mind to try out, which is closer to

:

, maybe too close(?), we’ll see, and that is

path/to:target;foo.py

. I like it, as it splits like a colon, almost. Edit: As John points out,

;

is of course not shell-safe either. All in all, I think that whatever symbol, that the order of size should be consistent in a target address. Either going from large to small, or small to large, isn’t all that important. Both is commonly used. But to mix them so you have

smallest X biggest Y middle

I think is a mistake.

;

is ruled out by bash just like

!

But to mix them so you have smallest X biggest Y middle I think is a mistake.

Good point, which I think is a reason

foo.py@path/to:tgt

reads the wrong way to me. It's smallest -> biggest -> middle

since

/

is banned in target names, it is also available:

3rdparty/python:requirements/Django

(for the

django

target generated by a

requirements

target)

Was thinking the same… almost feels like the

:

in the middle is a typo…

I think we want to allow

/

in the

generated_name

though.

src/py/project:lib#path/to/some_util.py

And I realized we should ban

:

in the

generated_name

. The

generated_name

is not really a target name like normal, because you can't have a generated target w/o referring back to its generator

Well, that’s still better, as the

#

takes up more space, and also that is not an unusual use of hash-parts in URLs for instance…

@hundreds-father-404: it’s fine to allow

/

in the generated name and still use it as a separator. everything after the

:

is in a different namespace

and also that is not an unusual use of hash-parts in URLs for instance…

Yeah I like that connection a lot for

#

. In a URL, people already know

#fragment

is how you get a more specific part of the entire page. Here, it's how you get a more specific target out of a generator target