Riddle me this batman: if

[docker].run_args

is args for

run

, why isn't

[docker].build_args

not args for

build

🫠

🙊

I think this summarizes my FUD around the deprecation proposal @flat-zoo-31952's been kind enough to work on. No current user benefits, but if we get something wrong, it's wrong forever and so future users can't intuit things because we can never fix it 😢 .

Wait what? (Not familiar with the docker plugin to follow this) And what are you suggesting would be better?

It'd be ideal if

build_args

were arg for

build

, as thats whats intuitive

yeah, the loopside here comes from trying to be transparent to docker’s way of naming things, and before looking at the UX for what Pants UX will look like for the

run

goal… that’s most unfortunate.

I mean, we always (myself included) could use a step back when adding any new feature and look at things holistically. But we're bound to get things wrong eventually. If not in a single PR like this one, than when the code evolves and we find better defaults/behavior

I did see this as we added the

run_args

and how

build_args

was something else… but couldn’t come up with a good way out of that hole…

But "build_args" has a very specific meaning in docker land, and we've avoided having a

build

goal for a whole host of reasons, but mainly it's way too generic for a build system like pants to have such a goal.

Ah see, further confusion 🫠

build_args

isn't for a

build

goal and neither is

run_args

for a

run

goal.

run_args

is args for the

run

subcommand of

docker

build_args

are

--build-arg

values for the

build

subcommand for

docker

there doesn't yet exist

<thing>_args

for the

build

subcommand of

docker

. Intuition would say

<thing>

is

build

(which mirrors

run_args

, and is a good name), but that's being squatted on 😞

intuition is a fickle, changing, context-dependent thing

I like that. And I even think that these docker backend args make sense, viewed in isolation from each other, it’s just together they don’t really sit well I think..

that's kinda what I mean...

./pants run

maps to

docker run

but

./pants package

maps to

docker build

... sorta

the most unfortunate thing is the docker “build args” thing that confuses this space, what should we call the options that works with those, and not the args to the “docker build” command?

build_build_args

Not a bad suggestion, and good food for thought. But the meta-point stands regarding "getting things wrong". field/option defaults are the ones that scare me the most. Get those wrong and we have to invent new names just for new defaults, or make new users set what should be the sensible default

Yeah, I get you. I proposed something extreme because it's easier to get a discussion going that way. I think there's room for exceptions here. Defaults are definitely something to think about, and it may just be that it varies on a case-by-case basis

FWIW defaults, I suspect, are actually really easy to break because by their very nature, the user isn't setting them 😛 Therefore if

./pants fix

knew a default was going to change in a future version it could then set the value to the current-default with a comment. Then the user can keep the old-default as hardcoded, or remove and use the new default when they upgrade. 🙂

That's a good point around defaults. Although I don't love

fix

for that because of the equivocation of "fix a problem" and "fix into place" like a "fixed location" 😄

I think it well mirrors other tools usage of

fix

. Fixing problems

but yeah, addressing the unfortunate option naming in the docker backend is a welcome exercise we can apply to the new deprecation policy to help shape it, if that was the idea? 🙂

latin is for nerds, let's use lojban to be extra precise and logical 🙃

I’ve heard of https://en.wikipedia.org/wiki/Esperanto before, but never lojban! 😄 thx for that. I’ve learned so many new things today 😛

No, and I think thats the script-writers burden. Although you could in an ideal world (options are just kebob cased, we could look for them in whatever file is specified 😛 )

keeping breaking changes to a minimum should allow scripts to keep functioning without too much interference… hopefully.

Yeah I think the fact that this is a command-line API makes fixers less effective than they would be, say, in a constrained language, but still perhaps more effective than in a web API. It still behooves us to avoid breaking changes when possible. But I agree we shouldn't make the experience worse for new users to do this. We just have to be frank about the limits of using things like fixers. One of the next steps I wanted to propose around this is using data to make these kinds of decisions. Theoretically there's telemetry being gathered on how this stuff gets actually used, and that could potentially make this whole conversation a lot more grounded and a lot less academic: if we know how people are calling Pants and with what options, we know the true cost of breaking things (to a point).

Oh right, my point from above. If you're using the flag, you aren't relying on the default 😛

Oh I was thinking about changing names... getting lost here haha

Our telementry isn't that powerful https://github.com/pantsbuild/pants/blob/1ef5a17f2bd331cc255c0af69fae18f808853115/src/python/pants/goal/anonymous_telemetry.py#L121

hmm, and I guess people may not like their command lines being recorded... so that would have to be a feature to be implemented