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

bitter-ability-32190

07/16/2022, 6:09 PM
New thread on what the goal name is for the goal: "if
fmt
fixes style, what fixes semantic issues?" Pile in thread: 🧵
I'm a huge fan of puns, and naming is hard. We can either try and use existing schemas (something akin to
fix
) or try and create a new one (a la
tailor
). There's pros and cons to either. I doubt we'll find an existing schema we can all agree on, so I suggest we consider a punny new one. Although too many of these and users get lost "what does
stitch
do again?" My current guesstimate is something to the tune of
mend
. 🤷‍♂️
😁 1
h

hundreds-father-404

07/16/2022, 6:20 PM
I think between
mend
vs
fix
is solid Sorry if this derails, but I continue to not love
lint
vs
check
. The split for sure makes sense, only I think it might be a little confusing how do you run `fix`/`mend` in check-only mode
c

curved-television-6568

07/16/2022, 6:24 PM
Fmt -
stretch
. Check only
lint
Fix -
retrofit
. Check only
lint
? (No need to have a separate goal for check only operation, maybe..?) Just playing with alternatives.
mend
as well as
fix
are both good options in my book.
b

bitter-ability-32190

07/16/2022, 6:26 PM
I was musing
style
for
fmt
, but let's not get derailed 😉
🙂 1
Also I was imagining that lint still runs fixers, as that follows existing schemas IMO
1
w

wide-midnight-78598

07/16/2022, 6:44 PM
I'm generally in the camp of not reinventing the wheel, avoiding not invented here, and other such acronyms/initialisms. Go/Rust picked up "fix" for differing purposes, and I really dislike that word because it's too general to have a meaning... Fix what? Lint stuff? Bugs? Upgraded APIs? It's general to the point of meaningless. May as well be called "Go DoSomething" However, I'm also REALLY against having to learn an entirely new language/grammar with no basis in common dev vernacular, because instead of allowing seamless context switching between projects - it actively and intentionally goes the other way. I say this with the full realization that my friends get annoyed with my daily punnery. If I were around 45+ years ago, I probably wouldn't have gone with
lint
either, but 🤷" - that's super common nowadays (for better or worse). As is format/fmt, build, compile, typecheck, test, package, init, deploy, publish, export, version, inspect, etc... Those verbs are not super ambiguous language to language or tool to tool, and any reasonable developer could approximately infer (within reason) what they should do. Tools (in-house or public) that make me sound like I'm quoting Harry Potter definitely make my blood boil. I think one of the worst examples was a backend pipeline that was something like "did you remember to deflux the capacitor before deployment" - thinking they were being clever.
👍 3
😄 3
2
h

hundreds-father-404

07/16/2022, 6:47 PM
I agree w/ SJ. I'm generally not a fan of puns for goal names because they're not intuitive. I like that most of our goals are common terms like
dependencies
and
test
So I'm generally much more pro
fix
than
mend
. Even though it's imperfect, just like
check
is very imperfect
1
Josh Reed had a good point that it's impossible to find the perfect names & API. This is a messy problem of trying to confine multiple distinct languages and tools into a smaller common interface
w

wide-midnight-78598

07/16/2022, 6:50 PM
I'd say there is an 80/20 here, where some language(s)/tool(s) have probably landed a reasonably apt name for what we're trying to achieve here. I think being crystal clear on what that new goal would do is the first step. I think a reasonable approach is re-visiting this page and making sure each goal is concise and unambiguous: https://www.pantsbuild.org/docs/python-goals If it can't be summarized here, then that's a bad place to implement from.
Actually, I thought there was even a more top-level table of goals +explanations
This conversation will also leak into whether we should have a separate
deploy
goal, and what the constraints there are, so coming up with loose rules here seems reasonable - with all the effort that has gone into this so far
h

hundreds-father-404

07/16/2022, 6:52 PM
./pants help goals
Copy code
check                                     Run type checking or the lightest variant of compilation available for a language.
fmt                                       Autoformat source code.
lint                                      Run all linters and/or formatters in check mode.
tailor                                    Auto-generate BUILD file targets for new source files.
update-build-files                        Format and fix safe deprecations in BUILD files.
b

bitter-ability-32190

07/16/2022, 7:01 PM
@happy-kitchen-89482 @witty-crayon-22786 and @enough-analyst-54434 all have opinions I hold in high regard. Do y'all have anything y'all feel about this?
h

happy-kitchen-89482

07/17/2022, 1:18 AM
Is it bad to put semantic fixes in
fmt
? I know it's a slight abuse of naming, but in practice maybe it's fine?
What are the circumstances in which you'd want to run only semantic fixes or only style fixes?
b

bitter-ability-32190

07/17/2022, 1:21 AM
The proposal and ticket (I think, I'm on mobile) highlight pain. Mainly
--loop
or running
fmt
on save. The fact that we haven't already probably says something as well?
E.g. I add an import or a variable that I'm about to use, then those get stripped away leaving me back where I started 🙈
1
I think the overall thought is centered around UX
h

happy-kitchen-89482

07/17/2022, 1:48 AM
Ah, I didn't see a ticket or proposal on this thread, I'll go check the other
OK, now I'm read up
So I think I'm convinced that
fix
is a good name for semantic fixes (and apparently there is prior art in go and rust and maybe scala in calling it that).
Why not keep
fmt
in perpetuity? Not sure I was convinced that we need to deprecate it.
The rule can be
fmt
is changes you don't need to eyeball,
fix
is for changes you probably should
2
b

bitter-ability-32190

07/17/2022, 10:32 AM
Yeah that's what we've landed on so far. Keep
fmt
plus add
XYZ
1
f

flat-zoo-31952

07/17/2022, 1:36 PM
I didn't like fix because it's such an incredibly general word (we have others of these like
check
that are too general as well and it seems people don't love those) and prior art disagrees a bit on what's included. (Rust vs Go)
Although I do I agree the Rust definition makes as much sense as anything (fix semantic errors my compiler or tools will complain about). The issue is if we choose not to include
go fix
style "update API" actions, it would be confusing to have a verb mismatch there, e.g. "to run
go fix
you need to run
./pants fix --update-api
or `./pants update-sources`" or whatever the naming would be for that. Basically if we want to use
fix
I think we need to be sure that it can sensibly incorporate all ideas of the native tooling that uses that that we're targeting. Right now I think Scala and Go are the only supported languages that have this command. So
./pants fix
should do at least what
go fix
does on Go targets and at least what Scala fix does on Scala targets.
An additional concern is: what if Go-style API update fixes become available on, say, Python, but necessarily require more oversight because of Pythons dynamic nature. Should they be included in
fix
? I don't have a great answer to that question, and it's kinda academic anyways since that doesn't really exist. But it highlights my concern about prior art having different ideas of what this word should mean
b

bitter-ability-32190

07/17/2022, 1:53 PM
I haven't used go, so maybe I'm naive. Why wouldn't we want to include
go fix
in this goal?
1
h

hundreds-father-404

07/17/2022, 1:54 PM
Yeah I would expect
go fix
to be included in
./pants fix
. You can use
./pants --go-fix-skip
or
./pants fix --only=pyupgrade
if you want to ignore it
Also for the record, I'm now on board with
fmt
and
fix
staying separate. I originally was proposing merging them
🎉 2
f

flat-zoo-31952

07/17/2022, 2:58 PM
Okay just wanted to raise that concern. Based on this, I think the best thing to do is to solicit the point of view of someone that uses Go regularly. If we're citing prior art, we should get the perspective of someone more familiar with that art. Just to see how
go fix
fits in their workflow, and if that jives with what we've discussed around this topic
w

wide-midnight-78598

07/17/2022, 5:02 PM
I think this would apply to
cargo fix
as well. I think it is a reasonable assumption that if you're a user of said language, that piping
./pants fix
down to that language's native(ish) version of that command is fair game - and you, as the developer, would understand the consequences. It's more about the languages that don't have that concept where I'm a bit more suss.
./pants fix cpplib
or
./pants fix pythonlib
- not sure what to expect.
b

bitter-ability-32190

07/17/2022, 6:30 PM
clang-tidy -fix
and tools like
pyupgrade
respectively?
👍 1
w

wide-midnight-78598

07/17/2022, 7:37 PM
Sure, but those also do wildly different things, and aren't really de facto uses of that verb in those languages. I happen to use clang-tidy, and also clang-tidy -fix, but there is an ecosystem of other lint/static analysis tools for C and C++ without the
fix
option. In my mind,
fix
might end up being any auto-correctable lint warning/error (like clang-tidy --fix, eslint --fix, etc). By virtue of adding the
pyupgrade
add-in, you're essentially stating that anything pyupgrade finds is a lint error, and since we can fix it - we will
fix
it. So, I view
fix
and
lint
as coupled goals (nothing wrong with that). Is there the chance that a
fix
goal would make changes that wouldn't otherwise show up as
lint
warnings/errors?
b

bitter-ability-32190

07/17/2022, 7:42 PM
Since we run fixers/formatters in the
lint
rule, 100% of things
fix
would change would cause a
lint
error 🙂
👍 1
And since lint runs these tools, they ARE coupled! The idea being CI can just run one command for all statically determined issues.
👍 2
h

hundreds-father-404

07/17/2022, 9:27 PM
can just run one command for all statically determined issues.
Sort of,
check
also is necessary; womp womp weirdness
w

wide-midnight-78598

07/18/2022, 12:09 AM
`check`mate
😂 2
w

witty-crayon-22786

07/19/2022, 3:56 AM
i’m in favor of
fix
due to the growing convention of rust, go, scala, etc. the line between
fmt
and
fix
being “syntactic vs semantic” changes is reasonably easy to explain. and
lint
and
check
remaining separate is important i think, although we need to continue to sharpen the line between them: to the extent that tools using transitive deps are in
lint
(
pylint
) they should probably be in
check
instead… they’re closer to being compilers than the traditional expectations of a linter.
1
6 Views