https://pantsbuild.org/ logo
Powered by
h

hundreds-father-404

11/05/2021, 11:22 PM
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

busy-vase-39202

11/05/2021, 11:27 PM
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

happy-kitchen-89482

11/05/2021, 11:31 PM
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

hundreds-father-404

11/05/2021, 11:32 PM
It's fully backwards compatible. But ack on not spending the time to do it yet
h

happy-kitchen-89482

11/05/2021, 11:33 PM
I'm concerned about ripple effects that we can't predict...
f

fast-nail-55400

11/05/2021, 11:50 PM
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

hundreds-father-404

11/05/2021, 11:51 PM
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

curved-television-6568

11/06/2021, 7:21 AM
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

busy-vase-39202

11/10/2021, 1:40 AM
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

hundreds-father-404

11/10/2021, 1:42 AM
Our docs already make clear you need to activate both, so in reality it's not a huge deal. Only a simplification
b

busy-vase-39202

11/10/2021, 1:43 AM
Dunno. If a maintainer is scratching his head, I gotta think there are others too.
3 Views
Powered by