> On Aug 17, 2019, at 10:12 PM, Benjamin Bannier <bbann...@apache.org> wrote:
>
> Hi,
>
> I opened MESOS-9360[^1] to improve the way we do linting in Mesos some time
> ago. I have put some polish on my private setup and now published it, and am
> asking for feedback as linting is an important part of working with Mesos
> for
> most of you. I have moved my workflow to pre-commit more than 6 months ago
> and
> prefer it so much that I will not go back to `support/mesos-style.py`.
>
> * * *
>
> We use `support/mesos-style.py` to perform linting, most often triggered
> automatically when committing. This setup is powerful, but also hard to
> maintain and extend. pre-commit[^2] is a framework for managing Git commit
> hooks which has an exciting set of features, one can often enough configure
> it
> only with YAML and comes with a long list of existing linters[^3]. Should we
> go with this approach we could e.g., trivially enable linters for Markdown
> or
> HTML (after fixing the current, sometimes wild state of the sources).
>
> I would encourage you to play with the [chain] ending in r/71300[^4] on some
> fresh clone (as this modifies your Git hooks). You need to install
> pre-commit[^5] _before applying the chain_, and then run
> `support/setup_dev.sh`. This setup mirrors the existing functionality of
> `support/mesos-style.py`, but also has new linters activated. This should
> present a pretty streamlined workflow. I have also adjusted the Windows
> setup,
> but not tested it.
>
> I have also spent some time to make transitioning from our current linting
> setup easier. If you are feeling adventurous you can apply the chain up to
> r/71209/ on your existing setup and run `support/setup_dev.sh`.
>
> One noticeable change is that with pre-commit we will store (some) linters
> in
> `$XDG_CACHE_HOME` (default: `$HOME/.cache`). The existing setup stores some
> linter files in the build directory, so a "clean build" might require
> downloading linter files again. With pre-commit OTOH one needs to perform
> garbage-collection out of band (e.g., by executing `pre-commit gc`, or
> deleting
> the cache directory).
>
> * * *
>
> Please let me know whether we should move forward with this change, you
> think
> it needs important adjustments, or you see fundamental reasons that this is
> a
> bad idea. If you like what you see here I would be happy to know about that
> as
> well.
I set this up and did a quick test commit. The only issue I hit was installing
pre-commit on Fedora 30 (I needed to do "python3 -m pip install pre-commit”).
This is a much more polished experience than the previous scripts, and I liked
it a lot.
J
