Hello! I was wondering if any SQL support is alrea...
# general
a
Hello! I was wondering if any SQL support is already being considered? We use sqlfluff for linting and formatting our .sql files, and it would simplify things if that could be done using pants. If it is not yet on the radar, I wouldn’t mind doing the work myself if someone can tell me how to get started 🙂
🙏 3
r
w
Shameless promos aside, as sqlfluff is a python lib, adding linters or formatters is suuuper easy nowadays. Some good example plugins to review: https://github.com/pantsbuild/pants/tree/main/src/python/pants/backend/python/lint/docformatter https://github.com/pantsbuild/pants/tree/main/src/python/pants/backend/cc/lint/clangformat These are formatters, but you can see, even in wildly different languages, the code is very similar (so much so, that there is a PR proposing to make a "meta linter" which reduces most of this boilerplate to a couple lines). The links here and above in this thread should give you a great intro (definitely read the Pants docs, as there are a lot of concepts to learn), and if you run into any issues, there are a ton of people on Slack willing to help out
a
Thanks @wide-midnight-78598, this is very helpful!
👍 1
h
that would be really neat for Pants to support sqlfluff 😄
h
That would be great! Adding linters is pretty straightforward. I’d love it if out of the box we could format/lint SQL, HTML, CSS, etc.
h
What we don't have are targets 😞
cc @bitter-ability-32190, we've been DMing about target-less formatters. I think I have a strategy to make it happen, only lacking the time
🤯 2
b
We might want to convene on an actual decision on targetless support for tools. Without a target they lack metadata. Specifically whether to skip the formatting (same for linting). You could argue that formatters/linters could be configured to ignore certain files/dirs, but not all do, or do well. And that's why i think we ought to sit and think about it first.
w
I would looooove that - especially with cross-language formatters
b
Yeah, I think it's a direction we want to head. Just wanna make sure we're intentional
1
h
Specifically whether to skip the formatting (same for linting).
Could be done via the config system. But yeah, agreed the story is important to figure out, including what happens if we start with a target-less formatter and want to migrate it Or maybe we let the user decide in which mode to invoke the tool, with the default being target-less because that's how The Real World works
h
Yeah target machinery seems like overkill here.
./pants lint '**/*.html'
should do the right thing
h
or
./pants lint src/html::
now 😉 CLI args consistently for target-less goals
h
That too
Assuming linters know how to ignore files they don’t operate on
h
Assuming linters know how to ignore files they don’t operate on
They do for linters. They have an
.is_applicable()
function 🙂
w
This feels like a moving train, but to pile on to the awesomeness of what it could mean - i love the idea of having Pants as my cross-repo, cross-language dev tool. I already do this to whatever extent I'm able to, but the idea that all my CI files, pre-commit, and workflow (unrelated to production source code) handled in one tool. ... the hours saved...
💯 1
I say this while literally having Android Studio and XCode open working on a project, and trying to remember my format scripts for each
h
@happy-kitchen-89482’s vision for a long time has been to dramatically reduce the need for targets, with the argument users don't think in terms of them. A lot of initiatives the past two hours have intended to get us closer: • file and dir arguments • dep inference • target generators • target-less linters • defaults • tailor • proposal to make
name=
much better
👍 1
b
I think I agree, if we don't need metadata (like just for formatting and maybe linting) no reason to force users to declare it
h
That’s a lot of progress in just two hours! 😉
😂 1