public inbox for linux-kbuild@vger.kernel.org
 help / color / mirror / Atom feed
From: Nathan Chancellor <nathan@kernel.org>
To: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc: Nicolas Schier <nsc@kernel.org>,
	Guillaume Tucker <gtucker@gtucker.io>,
	linux-kbuild@vger.kernel.org
Subject: Re: [PATCH 0/3] scripts/container: Minor fixups suggested by ruff
Date: Fri, 23 Jan 2026 14:01:28 -0700	[thread overview]
Message-ID: <20260123210128.GB95167@ax162> (raw)
In-Reply-To: <CANiq72mLBdW+XEB-BTgjngwRxgVTRzc1K6XiwBVRkSFu+108yw@mail.gmail.com>

On Fri, Jan 23, 2026 at 04:14:16PM +0100, Miguel Ojeda wrote:
> On Fri, Jan 23, 2026 at 12:27 AM Nathan Chancellor <nathan@kernel.org> wrote:
> >
> > This series fixes a few warnings that I see when running
> >
> >   $ ruff check --select C4,RUF scripts/container
> >
> > which were the few warnings from my personal ruff.toml that seemed most
> > interesting.
> 
> I haven't had time to look into the new container support yet, but
> having kernel Python scripts Ruff-clean sounds good in general, and I
> wonder -- should we consider having a `.ruff.toml` eventually?

I think that we should. Even something as simple as the one in the Ruff
docs would keep things consistent:

  https://docs.astral.sh/ruff/linter/#rule-selection

I guess the one problem there is consistency amongst developers (since
one's linting workflow is fairly personal) and having a wide range of
Python code across the tree but having a .ruff.toml for people to run if
they want it is harmless.

> At least we have a small `.pylintrc` already, which is quite recent by the way.

Ah, good to know!

> I think I recall you also using Black and/or Flake8, for
> ClangBuiltLinux-related bits perhaps?

We use Ruff and pylint for linting, yapf for formatting. Ruff can
replace flake8 outright with the right configuration in my experience.

Cheers,
Nathan

  reply	other threads:[~2026-01-23 21:01 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-22 23:27 [PATCH 0/3] scripts/container: Minor fixups suggested by ruff Nathan Chancellor
2026-01-22 23:27 ` [PATCH 1/3] scripts/container: Turn runtimes class variable into a tuple Nathan Chancellor
2026-01-23 20:34   ` Guillaume Tucker
2026-01-22 23:27 ` [PATCH 2/3] scripts/container: Use list comprehension in get_names() Nathan Chancellor
2026-01-23 20:38   ` Guillaume Tucker
2026-01-22 23:27 ` [PATCH 3/3] scripts/container: Use iterable unpacking for _get_opts() Nathan Chancellor
2026-01-23 20:45   ` Guillaume Tucker
2026-01-23 15:14 ` [PATCH 0/3] scripts/container: Minor fixups suggested by ruff Miguel Ojeda
2026-01-23 21:01   ` Nathan Chancellor [this message]
2026-01-23 23:55     ` Miguel Ojeda
2026-01-23 20:26 ` Guillaume Tucker
2026-01-23 23:46   ` Nathan Chancellor
2026-02-04  8:54 ` Masahiro Yamada

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=20260123210128.GB95167@ax162 \
    --to=nathan@kernel.org \
    --cc=gtucker@gtucker.io \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=nsc@kernel.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