public inbox for gentoo-portage-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Zac Medico <zmedico@gentoo.org>
To: gentoo-portage-dev@lists.gentoo.org, Alec Warner <antarus@gentoo.org>
Subject: Re: [gentoo-portage-dev] pylint progress
Date: Thu, 30 Jul 2020 00:44:39 -0700	[thread overview]
Message-ID: <8643487f-c90f-ec37-0674-5088648c1b6d@gentoo.org> (raw)
In-Reply-To: <CAAr7Pr91Zkpwj3eNk8uy+aDZi6+sN4fjGS-CmB0CLERyLganjA@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 2006 bytes --]

On 7/29/20 3:14 PM, Alec Warner wrote:
> Hi,
> 
> Recently I've begun to run pylint on the portage codebase. You can see
> some recent PRs on this[0][1][2]. Most of the linter errors I've
> fixed are what I consider 'fairly trivial'. In general I'm happy to
> disable errors (or instances of errors) in addition to resolving them.
> You can see some of this
> in https://github.com/gentoo/portage/pull/593/files where we just
> blanket disable a bunch of very numerous messages (either because I
> don't expect to ever fix them, or because they are more work that I
> think we should do at the moment.)
> 
> So I see essentially a few choices:
>  - (a) Do we fix errors in certain classes and run the linter as part of
> CI. This means that once we resolve errors of a certain class, we can
> enable that class of check and prevent new occurrences.

Yes, this is an extremely useful feature to included in our CI.

>  - (b) Do we just avoid running the linter as part of CI (perhaps
> because we are not far enough along on this journey) and focus our
> efforts to get to a point where we can do (a) without spamming CI?

I think it will be best if we arrange it so that we're not spammed with
recurring messages in every CI run. Otherwise, useful messages will be
difficult to recognize since they'll be drowned in noise.

>  - (c) What messages should we bother not fixing at all so we can just
> not work on those classes of error?
> 
> As an example of (c); I believe 'protected-access' is likely intrusive
> to fix and pointless for portage (cat is out of the bag) where as a
> message like W0612(unused-variable) is plausibly something we should fix
> throughout the codebase.

Sounds good.

> Similarly I think "E0602(undefined-variable)"
> is often a bug in how pylint treats our lazy initialized variables, so
> most of these are false positives.

I think it would be nice if we could enable the undefined-variable check.
-- 
Thanks,
Zac


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

      reply	other threads:[~2020-07-30  7:44 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-29 22:14 [gentoo-portage-dev] pylint progress Alec Warner
2020-07-30  7:44 ` Zac Medico [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8643487f-c90f-ec37-0674-5088648c1b6d@gentoo.org \
    --to=zmedico@gentoo.org \
    --cc=antarus@gentoo.org \
    --cc=gentoo-portage-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox