https://pantsbuild.org/ logo
#general
Title
# general
h

hundreds-father-404

09/15/2021, 3:02 AM
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 `@`:
That is,
//:reqs=Django
or
//:reqs@Django
?
is an option but also requires quotes. And we could technically use
:
again, but
dir/generator:generated
is confusing Do we stick with
!
, use
=
or
@
, or some wildcard we're not considering? Thoughts appreciated! See https://github.com/pantsbuild/pants/pull/12891 for the PR
e

enough-analyst-54434

09/15/2021, 3:03 AM
When, why, how often would you type these in the terminal?
h

hundreds-father-404

09/15/2021, 3:06 AM
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
b

bored-art-40741

09/15/2021, 3:07 AM
#
or
$
?
!
definitely sounds dangerous given commandline issues
🙌 1
There's also
+
h

hundreds-father-404

09/15/2021, 3:11 AM
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.)
e

enough-analyst-54434

09/15/2021, 3:12 AM
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?
h

hundreds-father-404

09/15/2021, 3:14 AM
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
p

proud-dentist-22844

09/15/2021, 3:23 AM
$
is also problematic on shells (at least bash+zsh) as that is a var reference.
👍 1
#
would work as it evokes a URL-like anchor - ie it also dives down
🙌 1
and in my quick tests, bash and zsh don't confuse a
#
in the middle of the word with a comment.
1
h

hundreds-father-404

09/15/2021, 3:38 AM
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!)
h

happy-kitchen-89482

09/15/2021, 4:25 AM
I do like
Django@3rdparty/python:reqs
now that I think of it
As John says, putting the generated first can make sense, as it's the more prominent thing in the mind of the user
And I agree that we shouldn't use symbols that have meaning in the shell, that's asking for trouble
And because of email addresses, people intuit
@
h

hundreds-father-404

09/15/2021, 4:33 AM
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?
c

curved-television-6568

09/15/2021, 5:27 AM
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.
1
Haha, re-reading my post, I see that I started with just that mixed up size order. 😛 Oh, well..
e

enough-analyst-54434

09/15/2021, 5:35 AM
;
is ruled out by bash just like
!
👍 2
h

hundreds-father-404

09/15/2021, 5:36 AM
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
w

witty-crayon-22786

09/15/2021, 4:12 PM
since
/
is banned in target names, it is also available:
3rdparty/python:requirements/Django
(for the
django
target generated by a
requirements
target)
it doesn’t … parse quite as easily for me as a reader though. possibly because it looks too much like a PATH
c

curved-television-6568

09/15/2021, 4:15 PM
Was thinking the same… almost feels like the
:
in the middle is a typo…
1
h

hundreds-father-404

09/15/2021, 4:16 PM
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
c

curved-television-6568

09/15/2021, 4:18 PM
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…
w

witty-crayon-22786

09/15/2021, 4:18 PM
@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
h

hundreds-father-404

09/15/2021, 4:19 PM
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
👍 1
https://github.com/pantsbuild/pants/pull/12891 is merged, going with
#
. Thanks everyone! And thanks @bored-art-40741 for the idea 🙌
🎉 1
2 Views