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

bitter-ability-32190

10/27/2022, 6:12 PM
Riddle me this batman: if
[docker].run_args
is args for
run
, why isn't
[docker].build_args
not args for
build
🫠
c

curved-television-6568

10/27/2022, 6:18 PM
🙊
b

bitter-ability-32190

10/27/2022, 6:20 PM
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 😢 .
f

flat-zoo-31952

10/27/2022, 6:23 PM
Wait what? (Not familiar with the docker plugin to follow this) And what are you suggesting would be better?
b

bitter-ability-32190

10/27/2022, 6:23 PM
It'd be ideal if
build_args
were arg for
build
, as thats whats intuitive
Then if user wanted a
--build-arg
arg, they could include it in
build_args
(thanks docker for that naming)
c

curved-television-6568

10/27/2022, 6:25 PM
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.
b

bitter-ability-32190

10/27/2022, 6:27 PM
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
c

curved-television-6568

10/27/2022, 6:27 PM
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…
f

flat-zoo-31952

10/27/2022, 6:34 PM
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.
"run_args" is our neologism, and if anything should be changed there, it should be that (although there's little harm in keeping
run_args
around as a hidden alias for whatever we change it to)
I don't want to block API improvements. But my FUD is that intuition is a fickle, changing, context-dependent thing. And using that to justify churn requires more evidence than a burst of inspiration, IMO
b

bitter-ability-32190

10/27/2022, 6:38 PM
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 😞
c

curved-television-6568

10/27/2022, 6:39 PM
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..
neither is
run_args
for a
run
goal.
well, isn’t that splitting hairs, as you use the
run
goal to get to the
docker run
part…
f

flat-zoo-31952

10/27/2022, 6:40 PM
that's kinda what I mean...
./pants run
maps to
docker run
but
./pants package
maps to
docker build
... sorta
For this particular issue, i'd say
run_extra_args
and
build_extra_args
should be the options that are used for passing extra args to their respective subcommands. In this case,
run_args
could be quietly aliased to
run_extra_args
. Although I'm not familiar enough with the use patterns to know if this makes sense exactly. Aren't some of these args injected by the rules around the goal?
c

curved-television-6568

10/27/2022, 6:47 PM
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?
f

flat-zoo-31952

10/27/2022, 6:47 PM
build_build_args
🙈 1
b

bitter-ability-32190

10/27/2022, 6:47 PM
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
3️⃣ 1
☝️ 1
f

flat-zoo-31952

10/27/2022, 6:49 PM
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
👍 1
Part of this is also a bit of a thought experiment for me (and others) to try to imagine what an API that evolves and pushes towards the new but does not break the old looks like. It's like an API koan.
b

bitter-ability-32190

10/27/2022, 6:51 PM
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. 🙂
💯 1
(And this will be possible very soon after I add a
pants.toml
fixer and a shitton of plumbing)
f

flat-zoo-31952

10/27/2022, 6:52 PM
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" 😄
Or maybe that was intentional?
c

curved-television-6568

10/27/2022, 6:53 PM
fix all my future problems now
b

bitter-ability-32190

10/27/2022, 6:54 PM
I think it well mirrors other tools usage of
fix
. Fixing problems
Let's just switch to Latin 🤷‍♂️
c

curved-television-6568

10/27/2022, 6:54 PM
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? 🙂
f

flat-zoo-31952

10/27/2022, 6:55 PM
latin is for nerds, let's use lojban to be extra precise and logical 🙃
😮 1
🤯 1
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?
Yes, sounds like a good case study. And maybe we can find a way to arrive at something more intuitive and sensible while perhaps not requiring a break. Or at least allowing a fixer to bridge the gap across the breaking change.
👍 1
But also remember that you can't apply fixers to scripts that wrap Pants 😄
c

curved-television-6568

10/27/2022, 6:58 PM
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 😛
b

bitter-ability-32190

10/27/2022, 6:58 PM
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 😛 )
c

curved-television-6568

10/27/2022, 6:59 PM
keeping breaking changes to a minimum should allow scripts to keep functioning without too much interference… hopefully.
👍🏻 1
f

flat-zoo-31952

10/27/2022, 7:03 PM
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).
But I haven't had time to formalize this or really even investigate whether this is realistic
b

bitter-ability-32190

10/27/2022, 7:03 PM
Oh right, my point from above. If you're using the flag, you aren't relying on the default 😛
f

flat-zoo-31952

10/27/2022, 7:04 PM
Oh I was thinking about changing names... getting lost here haha
f

flat-zoo-31952

10/27/2022, 7:06 PM
hmm, and I guess people may not like their command lines being recorded... so that would have to be a feature to be implemented
☝️ 1