[oslo] fix flake8-hacking inconsistences on xena/wallaby

Herve Beraud hberaud at redhat.com
Wed Mar 24 14:31:50 UTC 2021


Hello Sorin,

Thanks for your feedback, they are much appreciated.

Le mer. 24 mars 2021 à 13:45, Sorin Sbarnea <ssbarnea at redhat.com> a écrit :

> As one of the early adopters and supporters of pre-commit *tool* I should
> mention few things I observed.
>
> pre-commit tool by design does pin all the hooks/linters/checks, so it is
> mainly making use of 'hacking' package irrelevant. On many tripleo
> repositories we ended up removing hacking and I do not remember getting
> into any problems due to flake8 or its plugins so far..
>

Here our problem was that we recently started to define the version of
flake8 to use and that version wasn't compatible with the one supported by
hacking. The solution is simply to let hacking manage these own
requirements. We don't want to drop hacking.


> My personal recommendation is to avoid the use of "repo: local", especial
> for calling an external tools (flake8). This makes you loose the ability to
> upgrade the linter using `pre-commit auto-update`. Local hooks are designed
> for running custom checks hosted in-repo.
>

We don't want to use auto-update. We want to control the flow of supported
hacking versions and its supported rules. We don't want to suffer each new
version of hacking.


> Sidenote: when using additional dependencies with pre-commit, there is no
> pinning, so there is still a chance you may want to use hacking or at least
> manually control the version of the extra packages you want to inject
> inside the "hook".
>

Please can you share docs or links that refer to this point? I didn't find
that point in the official documentation.

https://pre-commit.com/#config-additional_dependencies

>
> If we still have a strong case for using hacking, I think it should be
> converted to be usable as a hook itself, one that calls flake8. If doing
> this it will be possible to make use of pre-commit pin to tag and fully
> control the bumping of flake8 with all the deps involved.
>

Indeed, it's a good idea.

--
> /zbr
>
>
> On 23 Mar 2021 at 11:00:42, Herve Beraud <hberaud at redhat.com> wrote:
>
>> Hello Osloers,
>>
>> As you surely recently observed patches proposed by the openstack bot to
>> configure wallaby fail with a flake8/hacking issue.
>>
>> Here are some guideline to fix the problem the inconsistency:
>> - Patch pre-commit on master (now xena) (here is the patch:
>> https://gist.github.com/4383/6e96c836bb1b0e1e0e599a5106f43f1a)
>> - Once Xena is patched cherry-pick and backport these changes on Wallaby
>> - Rebase the openstack bot patches on the top of this cherry-pick (or
>> wait for the merge of the previous one patch)
>>
>> You can copy the patch on oslo.db with the related commit message [1].
>>
>> The root cause of the issue was that with the introduction of pre-commit
>> we started to define the version of flake8 to use. Previously this version
>> was defined by hacking's requirements.
>>
>> Indeed a few months ago we added pre-commit to allow us to run checks
>> with git hooks and reduce the usage of our gates. These changes were
>> standardized and spread on all the scope of oslo [2].
>>
>> However, during the design of these changes [3] and after some discussion
>> we decided to pin the version of flake8 to use, hence by doing this we
>> short circuited hacking on its management of flake8.
>>
>> The solution to solve this issue is simply to trust hacking on its flake8
>> management. Hacking will pull the right version of flake8 and the
>> inconsistency will disappear. flake8 provides a pre-commit hook so it could
>> be seen and called as a local target.
>>
>> [1] https://review.opendev.org/c/openstack/oslo.db/+/781470
>> [2] https://review.opendev.org/q/topic:%22oslo-pre-commit%22
>> [3]
>> https://review.opendev.org/q/topic:%22pre-commit%22+(status:open%20OR%20status:merged)+project:openstack/oslo.cache
>>
>> --
>> Hervé Beraud
>> Senior Software Engineer at Red Hat
>> irc: hberaud
>> https://github.com/4383/
>> https://twitter.com/4383hberaud
>> -----BEGIN PGP SIGNATURE-----
>>
>> wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+
>> Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+
>> RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP
>> F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G
>> 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g
>> glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw
>> m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ
>> hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0
>> qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y
>> F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3
>> B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O
>> v6rDpkeNksZ9fFSyoY2o
>> =ECSj
>> -----END PGP SIGNATURE-----
>>
>>

-- 
Hervé Beraud
Senior Software Engineer at Red Hat
irc: hberaud
https://github.com/4383/
https://twitter.com/4383hberaud
-----BEGIN PGP SIGNATURE-----

wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+
Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+
RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP
F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G
5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g
glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw
m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ
hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0
qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y
F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3
B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O
v6rDpkeNksZ9fFSyoY2o
=ECSj
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210324/2ed3fef9/attachment-0001.html>


More information about the openstack-discuss mailing list