<div dir="ltr"><div>Hello Sorin,</div><div><br></div><div>Thanks for your feedback, they are much appreciated.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 24 mars 2021 à 13:45, Sorin Sbarnea <<a href="mailto:ssbarnea@redhat.com">ssbarnea@redhat.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="ltr">As one of the early adopters and supporters of pre-commit *tool* I should mention few things I observed.<div><br></div><div dir="ltr">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..</div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="ltr"><div dir="ltr"><br></div><div dir="ltr">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.</div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="ltr"><div dir="ltr"><br></div><div>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".</div></div></div></blockquote><div><br></div><div>Please can you share docs or links that refer to this point? I didn't find that point in the official documentation.</div><div><br></div><div><a href="https://pre-commit.com/#config-additional_dependencies">https://pre-commit.com/#config-additional_dependencies</a></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="ltr"><div dir="ltr"></div><div dir="ltr"><br></div><div dir="ltr"><div dir="ltr">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.</div></div></div></div></blockquote><div><br></div><div>Indeed, it's a good idea. <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="ltr"><div dir="ltr"><div>--<br></div></div><div dir="ltr"><div><div><div dir="ltr"><div>/zbr</div></div></div></div><div dir="ltr">
<br><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On 23 Mar 2021 at 11:00:42, Herve Beraud <<a href="mailto:hberaud@redhat.com" target="_blank">hberaud@redhat.com</a>> wrote:<br></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><div>Hello Osloers,</div><div><br></div><div>As you surely recently observed patches proposed by the openstack bot to configure wallaby fail with a flake8/hacking issue.<br></div><div><br></div><div>Here are some guideline to fix the problem the inconsistency:</div><div>- Patch pre-commit on master (now xena) (here is the patch: <a href="https://gist.github.com/4383/6e96c836bb1b0e1e0e599a5106f43f1a" target="_blank">https://gist.github.com/4383/6e96c836bb1b0e1e0e599a5106f43f1a</a>)</div><div>- Once Xena is patched cherry-pick and backport these changes on Wallaby</div><div>- Rebase the openstack bot patches on the top of this cherry-pick (or wait for the merge of the previous one patch)</div><div><br></div><div>You can copy the patch on oslo.db with the related commit message [1].<br></div><div><br></div><div>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. <br></div><div><br></div><div>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].<br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>[1] <a href="https://review.opendev.org/c/openstack/oslo.db/+/781470" target="_blank">https://review.opendev.org/c/openstack/oslo.db/+/781470</a></div><div><div>[2] <a href="https://review.opendev.org/q/topic:%22oslo-pre-commit%22" target="_blank">https://review.opendev.org/q/topic:%22oslo-pre-commit%22</a></div><div>[3] <a href="https://review.opendev.org/q/topic:%22pre-commit%22+(status:open%20OR%20status:merged)+project:openstack/oslo.cache" target="_blank">https://review.opendev.org/q/topic:%22pre-commit%22+(status:open%20OR%20status:merged)+project:openstack/oslo.cache</a></div></div><div><br>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Hervé Beraud</div><div>Senior Software Engineer at Red Hat</div><div>irc: hberaud</div><div><a href="https://github.com/4383/" target="_blank">https://github.com/4383/</a></div><div><a href="https://twitter.com/4383hberaud" target="_blank">https://twitter.com/4383hberaud</a><br></div><div>-----BEGIN PGP SIGNATURE-----<br><br>wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+<br>Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+<br>RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP<br>F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G<br>5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g<br>glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw<br>m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ<br>hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0<br>qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y<br>F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3<br>B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O<br>v6rDpkeNksZ9fFSyoY2o<br>=ECSj<br>-----END PGP SIGNATURE-----<br><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</blockquote>
</div>
</div>
</div></div></div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Hervé Beraud</div><div>Senior Software Engineer at Red Hat</div><div>irc: hberaud</div><div><a href="https://github.com/4383/" target="_blank">https://github.com/4383/</a></div><div><a href="https://twitter.com/4383hberaud" target="_blank">https://twitter.com/4383hberaud</a><br></div><div>-----BEGIN PGP SIGNATURE-----<br><br>wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+<br>Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+<br>RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP<br>F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G<br>5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g<br>glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw<br>m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ<br>hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0<br>qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y<br>F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3<br>B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O<br>v6rDpkeNksZ9fFSyoY2o<br>=ECSj<br>-----END PGP SIGNATURE-----<br><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div>