Bike shed opportunity - feedback welcomed! We're a...
# general
h
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
When, why, how often would you type these in the terminal?
h
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
#
or
$
?
!
definitely sounds dangerous given commandline issues
🙌 1
There's also
+
h
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
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
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
$
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
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
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
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
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
;
is ruled out by bash just like
!
👍 2
h
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
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
Was thinking the same… almost feels like the
:
in the middle is a typo…
1
h
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
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
@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
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