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)

this is a really interesting idea

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

maybe an intermediate solution would be to consider a "do what i mean" or "dwim" concept

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

and right now the bare goal doesn't do anything, so it is kind of open for assigning some meaning to

right.

we could make that true by updating some goals, if we wanted to do this, though

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”

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.

i’m not sure. these options are all mutually exclusive because they are “the ways to specify input targets”

I kinda like this idea (of no-spec meaning operate on changed) if we can make it coherent

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)

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.”

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

Most the credit goes to Benjy ❤️ I added the “Goal options” part, but the rest was him

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.

How does a user know what takes targets and what doesn’t? Trial and error?

that is an existing and open question 😃

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.

this is why i like decoupling output from other parts of pants, e.g. with https://github.com/pantsbuild/pants/pull/8765

i’m not sure how workunits are related… should maybe start a new thread for that.

i would agree that it would be important for this to do something consistent across all goals that take files/targets.

Very strongly agreed.

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

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

i think it's easier to go from "configurability" => "better defaults" than to find a default and hardcode it