New thread on what the goal name is for the goal: "if

fmt

fixes style, what fixes semantic issues?" Pile in thread: 🧵

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

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.

I was musing

style

for

fmt

, but let's not get derailed 😉

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.

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

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.

./pants help goals

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.

@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?

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?

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?

Ah, I didn't see a ticket or proposal on this thread, I'll go check the other

Yeah that's what we've landed on so far. Keep

fmt

plus add

XYZ

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)

I haven't used go, so maybe I'm naive. Why wouldn't we want to include

go fix

in this goal?

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

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

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.

clang-tidy -fix

and tools like

pyupgrade

respectively?

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?

Since we run fixers/formatters in the

lint

rule, 100% of things

fix

would change would cause a

lint

error 🙂

can just run one command for all statically determined issues.

Sort of,

check

also is necessary; womp womp weirdness

`check`mate

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.