https://pantsbuild.org/ logo
Join Slack
Powered by
I think we should maybe make it easier to onboard ...
# general
h
I think we should maybe make it easier to onboard using Pants only for formatters/linters w/ a language. Right now, you have to set this:
Copy code
[GLOBAL]
backend_packages = [
  "pants.backend.shell",
  "pants.backend.shell.lint.shellcheck",
]
Should maybe just require 
pants.backend.shell.lint.shellcheck
? Thoughts welcomed! šŸ§µ
Why? Easier to onboard, and you don't have to activate functionality you don't need. Like activating only Black doesn't activate 
pex_binary
and Pytest, whereas now you have to activate 
pants.backend.python
The linters would activate the bare minimum they need to work robustly in that language: i.e. ā€¢ the target types for targets describing source code (e.g. 
python_source
and 
python_test
) ā€¢ 
tailor
ā€¢ for linters that require dependencies, activate dependency inference rules
b
I think it does make sense to start with a linter enabled by default. Odds are higher that a person will want linting than not, and every time we shave off a step in the adoption process we're strengthening the contrast between Pants and <waves hands> everything else.
h
If it's extremely trivial to do it might make sense, but I do not want to embark on even minor side projects that might end up being destabilizing even in minor ways
h
It's fully backwards compatible. But ack on not spending the time to do it yet
h
I'm concerned about ripple effects that we can't predict...
f
If we are worries about config issues, maybe a config wizard would be better?
Ask some questions and write/update an appropriate pants.toml
We could even just have that as a web form on the toolchain site.
h
We used to have something to generate 
pants.toml
, and then deleted because we didn't think it was worth having a goal permanently for one-time setup We could probably retcon 
tailor
to do it though, something like 
tailor --init
. It'd be cool to update 
.gitignore
etc. It is kind of silly we have this advanced build system and you're still copying around `.gitignore`s etc
šŸ‘ 1
c
I tried this with the hadolint backend. I simply register all the rules from the docker backend, so it works but you don't get the target types for your build files. So it'll be the same as registering both backends. (bar the targets).
To me, it makes sense if you get all what you need from each backend, in isolation (even if it enables multiple backends behind the scenes). It's not great if you can have broken functionality because you've misconfigured what backends to load.
šŸ‘ 1
Also, it would be great to include which backend is responsible for each documented feature, such as goals, subsystems and targets. Sometimes I scratch my head trying to figure out what to load in order to get feature X.
āž• 1
b
Maybe add a "Requires: 
_______
<docslink> backend enabled" at the top of each of those pages? No one should have to be scratching their head over that.
h
Our docs already make clear you need to activate both, so in reality it's not a huge deal. Only a simplification
b
Dunno. If a maintainer is scratching his head, I gotta think there are others too.
3 Views
Open in Slack
PreviousNext
Powered by