https://pantsbuild.org/ logo
#development
Title
# development
w

witty-crayon-22786

05/01/2020, 7:31 PM
a bit left field, but: thoughts on changing the default “no specs” behavior to the equivalent of
--changed
(add adding a default value for
--changed-parent
presumably)
a

aloof-angle-91616

05/01/2020, 7:31 PM
this is a really interesting idea
h

hundreds-father-404

05/01/2020, 7:43 PM
I don’t think that’s a great idea because it’s surprising and not discoverable. The default for
--changed-since
is very interesting, though. And maybe we give it a short flag name since it’s such a common idiom. Related: where should information on using
--changed
since live in the new docs? https://pants.readme.io/docs/welcome-to-pants I’m thinking we want a dedicated page on something like “advanced target selection”. This is where
--query
would live. For now, it would talk about
--changed
. Once
filter
is ported, that too. We talk about file args vs target args in https://pants.readme.io/docs/targets
a

aloof-angle-91616

05/01/2020, 8:07 PM
maybe an intermediate solution would be to consider a "do what i mean" or "dwim" concept
it's a pattern used a lot in emacs
where some keybinding triggers a context-dependent action
w

witty-crayon-22786

05/01/2020, 8:09 PM
I don’t think that’s a great idea because it’s surprising and not discoverable.
so, i think that it’s potentially very discoverable as long as it explains what it is doing (in a log message maybe). because i expect that a lot of folks end up running the bare goals before learning about targets
a

aloof-angle-91616

05/01/2020, 8:10 PM
and right now the bare goal doesn't do anything, so it is kind of open for assigning some meaning to
w

witty-crayon-22786

05/01/2020, 8:10 PM
right.
(…for most goals. a slight risk here.)
a

aloof-angle-91616

05/01/2020, 8:10 PM
we could make that true by updating some goals, if we wanted to do this, though
w

witty-crayon-22786

05/01/2020, 8:42 PM
re: https://pantsbuild.slack.com/archives/C0D7TNJHL/p1588363763457700?thread_ts=1588361479.454400&cid=C0D7TNJHL … i’m thinking things like “you’re on a clean branch: nothing to ${goal}! try passing a target to ${goal}.” or “no targets specified, ${goal}’ing changed targets since ${mergebase}. press ctrl+c to cancel”
h

hundreds-father-404

05/01/2020, 8:48 PM
Instead, I think it’s better to put our energy into making
--changed-since
more ergonomic. For example, we could get this down to 3 characters:
./pants -csh fmt
, which is an alias for
--changed-since=HEAD
. Those 4 extra characters remove any possible ambiguity + allow us to add things like
-csm
for
--changed-since=master
. There’s also a grey area with the proposal for goals that expect no targets, like
./pants roots
and
./pants target-types
. When I say
./pants roots
, is it operating on the changed targets? Or it takes no arguments? Without prior knowledge or documentation, you lose the ability to reason about this.
w

witty-crayon-22786

05/01/2020, 8:50 PM
i’m not sure. these options are all mutually exclusive because they are “the ways to specify input targets”
in that regard, the “no targets were passed” syntax is available for usage.
i think that if we can think of something else that we would eventually want
./pants test
with no other arguments to do, then that would be another thing.
h

happy-kitchen-89482

05/01/2020, 8:51 PM
I kinda like this idea (of no-spec meaning operate on changed) if we can make it coherent
w

witty-crayon-22786

05/01/2020, 8:52 PM
with
--owner-of
we started out with a flag, and eventually made it syntax, and that has been a huge win (yay @hundreds-father-404)
--changed
started out as a separate goal, and is now a flag like
--owner-of
used to be.
the roots used to be mutually exclusive three ways: 1) owner-of, 2) changed, 3) literal targets
h

hundreds-father-404

05/01/2020, 8:54 PM
if we can think of something else that we would eventually want ./pants test with no other arguments to do, then that would be another thing.
That something else == consistent behavior with goals which take no arguments, like
roots
and
target-types
. Regardless of the goal, no arguments means no arguments. Please scan the docs section on goal arguments (revised yesterday): https://pants.readme.io/docs/goals#goal-arguments. I’m concerned the impact this would have on teaching Pants to new users, especially the day-to-day users who are not in this Slack / not the Pants administrator. That section of the docs would become confusing if “sometimes no arguments means --changed-since=master but sometimes goals take no arguments so no arguments mean no arguments.”
(To be clear, I am all for making
--changed-since
more ergonomic)
w

witty-crayon-22786

05/01/2020, 8:56 PM
will do. but similar to
help
, i think there are a few goals that are inherent and informational, and we should be careful about biasing toward their ease of use when compared to the things that folks use all day long
that page is great, thank you.
h

hundreds-father-404

05/01/2020, 8:58 PM
Most the credit goes to Benjy ❤️ I added the “Goal options” part, but the rest was him
w

witty-crayon-22786

05/01/2020, 8:59 PM
but i think that page might actually be clarified by drawing a harder line between goals that operate on targets/files and everything else. it’s called out there, but i think that similar to how
./pants roots $target
should fail fast saying it doesn’t accept a target it would not be odd for not providing a target to not trigger changed behavior there.
…whoa. triple negative.
h

hundreds-father-404

05/01/2020, 9:00 PM
How does a user know what takes targets and what doesn’t? Trial and error?
w

witty-crayon-22786

05/01/2020, 9:00 PM
that is an existing and open question 😃
and almost orthogonal to this one.
currently we would error if you ran
./pants test
(i hope?)… doing something other than erroring feels like it helps with discoverability… as long as it is very vocal about what it is doing.
h

hundreds-father-404

05/01/2020, 9:03 PM
One thing that DWH did a good job to remind me of when adding file args: remember that many users run Pants via scripts. That logging flow might work out well when running normally, but script users would miss it.
currently we would error if you ran ./pants test
We no-op. There have been a few discussions about what it should do, like warning like
list
does.
a

aloof-angle-91616

05/01/2020, 9:03 PM
this is why i like decoupling output from other parts of pants, e.g. with https://github.com/pantsbuild/pants/pull/8765
w

witty-crayon-22786

05/01/2020, 9:05 PM
i’m not sure how workunits are related… should maybe start a new thread for that.
We no-op. There have been a few discussions about what it should do, like warning like 
list
 does.
mm. i would agree that it would be important for this to do something consistent across all goals that take files/targets.
h

hundreds-father-404

05/01/2020, 9:12 PM
i would agree that it would be important for this to do something consistent across all goals that take files/targets.
Very strongly agreed.
a

aloof-angle-91616

05/01/2020, 9:13 PM
i’m not sure how workunits are related… should maybe start a new thread for that.
it's about pants output and options that redirect it to specific places. we can use this to make the choice of where to display output a user choice instead of a required convention
w

witty-crayon-22786

05/01/2020, 9:13 PM
but i do think that we need to draw a line between goals that operate on files/targets and everything else… those goals are the bread and butter
mm, this is more about “better defaults” than “adding configurability”
👍 1
a

aloof-angle-91616

05/04/2020, 3:09 AM
i think it's easier to go from "configurability" => "better defaults" than to find a default and hardcode it