Implement flake8-i18n

[leiserfg]

• Add skelleton code
• Add fixtures for flake8_i18n
• Add tests
• Add implementation and insta snapshots
• Add license entry

Closes #3294.

[github-actions]

PR Check Results

Ecosystem

ℹ️ ecosystem check detected changes. (+1, -0, 0 error(s))

zulip (+1, -0)

+ corporate/lib/stripe.py:1010:17: INT001 f-string is resolved before function call; consider `_("string %s") % arg`

Benchmark

Linux

group                                      main                                   pr
-----                                      ----                                   --
linter/all-rules/large/dataset.py          1.00     14.5±0.08ms     2.8 MB/sec    1.00     14.5±0.06ms     2.8 MB/sec
linter/all-rules/numpy/ctypeslib.py        1.00      3.8±0.03ms     4.4 MB/sec    1.00      3.8±0.02ms     4.4 MB/sec
linter/all-rules/numpy/globals.py          1.01    435.3±1.56µs     6.8 MB/sec    1.00    433.0±1.58µs     6.8 MB/sec
linter/all-rules/pydantic/types.py         1.00      6.4±0.02ms     4.0 MB/sec    1.02      6.5±0.05ms     3.9 MB/sec
linter/default-rules/large/dataset.py      1.01      7.9±0.06ms     5.2 MB/sec    1.00      7.8±0.04ms     5.2 MB/sec
linter/default-rules/numpy/ctypeslib.py    1.01   1712.6±9.61µs     9.7 MB/sec    1.00   1694.7±2.78µs     9.8 MB/sec
linter/default-rules/numpy/globals.py      1.00    175.8±0.89µs    16.8 MB/sec    1.01    177.0±0.44µs    16.7 MB/sec
linter/default-rules/pydantic/types.py     1.01      3.7±0.01ms     6.9 MB/sec    1.00      3.6±0.01ms     7.0 MB/sec

Windows

group                                      main                                   pr
-----                                      ----                                   --
linter/all-rules/large/dataset.py          1.00     15.5±0.13ms     2.6 MB/sec    1.00     15.6±0.15ms     2.6 MB/sec
linter/all-rules/numpy/ctypeslib.py        1.00      4.2±0.06ms     4.0 MB/sec    1.00      4.2±0.05ms     4.0 MB/sec
linter/all-rules/numpy/globals.py          1.01    463.1±7.69µs     6.4 MB/sec    1.00    458.3±8.02µs     6.4 MB/sec
linter/all-rules/pydantic/types.py         1.00      6.9±0.08ms     3.7 MB/sec    1.00      6.9±0.10ms     3.7 MB/sec
linter/default-rules/large/dataset.py      1.00      8.3±0.06ms     4.9 MB/sec    1.00      8.3±0.06ms     4.9 MB/sec
linter/default-rules/numpy/ctypeslib.py    1.00  1785.6±17.06µs     9.3 MB/sec    1.01  1794.8±17.34µs     9.3 MB/sec
linter/default-rules/numpy/globals.py      1.00    185.5±2.06µs    15.9 MB/sec    1.00    185.5±6.65µs    15.9 MB/sec
linter/default-rules/pydantic/types.py     1.01      3.9±0.03ms     6.6 MB/sec    1.00      3.9±0.03ms     6.6 MB/sec

[MichaReiser]

Nit:

Suggested change

	if let Some(diagnostic) =
	flake8_i18n::rules::f_string_in_i18n_func_call(args)
	{
	self.diagnostics.push(diagnostic);
	}
	self.diagnostics.extend(flake8_i18n::rules::f_string_in_i18n_func_call(args))

[MichaReiser]

Can we use Vec<String> directly or is it important to know whether the settings where empty vs None

[leiserfg]

True, it's fine to use a regular Vec here.

[leiserfg]

After this change tests are failing in CI but no idea why, 'cause they pass locally.

[leiserfg]

I see, some changes in main, I will rebase to fix them.

[charliermarsh]

Nice work here. I made a few minor but otherwise merging as-is. Thanks for getting involved :)

[charliermarsh]

I changed this to use an iterator.

[AA-Turner]

@charliermarsh -- I'm not certain on this but wanted to ask the question -- does including a GPL tool in Ruff mean that (all/part of) Ruff would be considered a derivative work for the purposes of GPL, and therefore that Ruff would need to be re-licenced (or this PR reverted or etc)? This is the first GPL tool to be integrated, and I wanted to flag the concern as early as possible. Thanks, Adam

[charliermarsh]

Lemme look into it.

[leiserfg]

There are already other parts including GPL3 (flake8-django for instance).

• edit: well only that one, but I think GPL3 is even more infectious than GPL2.

[charliermarsh]

I'll have to get some more informed opinions on this, I'm not sure myself on whether these constitute derivative works.

If they do, and we'd have to re-license under GPL, then I'd err on the side of removing them, or going back to the authors and asking if they'd consider re-licensing under MIT or a dual license.

flake8-django is confusing because on PyPI it appears dual-licensed, and it includes the MIT trove classifiers:

[AA-Turner]

I'll have to get some more informed opinions on this, I'm not sure myself on whether these constitute derivative works.

Sorry to cause the trouble and thank you both for looking in to this.

flake8-django is confusing because on PyPI it appears dual-licensed, and it includes the MIT trove classifiers:

It seems this has been noted already: rocioar/flake8-django#101 and rocioar/flake8-django#102. Sorry not to have flagged this at the time for flake8-django, but it seems the MIT trove classifier may have been a mistake when that project adopted Poetry.

A

[charliermarsh]

No, thank you for calling this out! It's important to get right. I'll try to reach out to the flake8-django maintainer.

[mvaled]

Hum... This is such a common "idea", I've done it before without even knowing about flake8-i18n. We were working in a project and switched to Python 3.6 and many members of a the team started to use f-strings inside _. I became such a common mistake we had to "invent" our checker.

I'm not a lawyer, but I don't think this can be gathered as derivative work.

[leiserfg]

@charliermarsh should I talk to @vharitonsky to see if he can change the license for us or will you do it?

[charliermarsh]

@leiserfg - If you're willing to that'd be great.

[leiserfg]

To be honest, I don't think this can be considered derivative work as we barely used some of their ideas, and ideas can be patented but not copyrighted.

[leiserfg]

@charliermarsh I found another implementation that does basically the same and is licensed under BSD, is it fine if we reference that one instead?

[charliermarsh]

@leiserfg - Yeah that looks fine to me. I do think we could in theory include these rules without referencing flake8-i18n, especially since the issue that was raised on Ruff pre-dated any knowledge of that plugin. But it seems most straightforward to base it on flake8-gettext. Want to put up a PR?

[charliermarsh]

Let's continue to use the INT codes (which I think differs from either of those plugins).

[leiserfg]

#3785

[charliermarsh]

Thx!