Patched for flake8 version 5

[wieczorek1990]

flake8 version 5 removes flake8.options.config.ConfigFileFinder therefore config file finding is broken.
Possibly a commit on flake8 would be required to move the tuple with config file names to a variable.
https://github.com/PyCQA/flake8/blob/main/src/flake8/options/config.py#L31

[wieczorek1990]

Guys at flake8 don't want us to monkey patch.

Either way I copied the method and extended it to include pyproject.toml in checking.

Is now flake8 version 5 compatible.

[wieczorek1990]

@csachs Can you please review?

[schinckel]

Could we just wrap the function call instead of rewriting it?

I think flake8-pyproject did that; but I think this implementation does a better job of finding enclosing folders that contain a pyproject.toml file.

[wieczorek1990]

Hey @schinckel the current implementation on flake8 is a method with hardcoded list of candidate filenames.
We could do something like:

def _find_config_file(path: str) -> Optional[str]:
    result = flake8.options.config._find_config_file(path)
    if result is None:
        result = ...
    return result

But... without extracting methods from original _find_config_file it is basically the same method with a different list containing only ours pyproject.toml. I wrote a patch about extracting this candidate filename list, but it wasn't accepted.
In what way do you want to wrap the function call?
I don't want to change the logic of the original function.

[schinckel]

Yeah, that was what I was thinking about: but we'd possibly need to run our finder first.

[wieczorek1990]

The finder code will be the same, equals duplication again.

[johnthagen]

For reference, the rejected related upstream patch:

• Extracted list of config filename so that it can be overriden PyCQA/flake8#1634 (comment)

[DaanRademaker]

Is this ready to be merged?

[johnthagen]

Not a lot of public GitHub activity lately: https://github.com/csachs

@csachs Would you consider adding another developer or two as maintainers?

It's within his right to disappear from the project, so we may need to consider a friendly fork with a robust set of maintainers who have time to be responsive (especially given how upstream Flake8 changes could break this project at any time).

I reached out to Christian over email to see if he has to time to help with this. I want to avoid spamming him too much, so maybe after some time if there is no response (which is totally within his rights) the community can discuss a friendly fork.

[csachs]

Sorry for the absence, I'm quite busy lately with my job (and had some vacations away from the computer).
I merged two smaller things and will take a look at this PR later.
Concerning maintainers, I'd happily add some other people, I'll just have to set the infrastructure in place so that they could release new packages to PyPI as well.
Who would want to help in maintaining?

[johnthagen]

I'm quite busy lately with my job

No worries! We all understand.

I'd be willing to be a maintainer to help with small fixes and getting releases onto PyPI.

My PyPI account: https://pypi.org/user/johnthagen/

[johnthagen]

@wieczorek1990 The README currently says:

while solving its task (with currently around 40 lines).

With this patch, it's now 67 lines of code. Perhaps we should simply remove the number of lines from the README?

[wieczorek1990]

Maybe change to „with little lines”. W dniu pon., 8.08.2022 o 15:23 johnthagen ***@***.***> napisał(a):

…

@wieczorek1990 <https://github.com/wieczorek1990> The README currently says: while solving its task (with currently around 40 lines). With this patch, it's now 67 lines of code. Perhaps we should simply remove the number of lines from the README? — Reply to this email directly, view it on GitHub <#14 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMRLK6INXO4KVYV6VTYQXDVYEC3VANCNFSM55GO6GRA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[csachs]

So, now I've read up the issue, PR and referencing PRs/issues a bit to get a better view of the situation.
Obviously such a change, in particular if it makes the formerly rather straight-forward monkey patching more difficult, is a sad occurrence for this little wrapper.

I'm sorry for not having reacted earlier, this package has gotten more popular in the past months than I had anticipated.

Thank you @wieczorek1990 and @johnthagen for looking into this.

As a first step, I've cherry picked c749077 to main, so there is a working, flake8 4.x based version on PyPI.

Concerning the way to address the changes, I'm somewhat reluctant of copying over the whole function; on one hand, it raises the need to stay in sync more closely, and on the other may introduce the need to specifically act on flake8's license terms if non-trivial amounts start to get copied (which is not really an issue, since it's a MIT license,, but just something to keep in mind).

Therefore my proposal would be to perform the monkey patching a bit rougher by modifying the AST.
Please check #15 .

(If the general opinion gravitates more to copying the function, we can look into this as well.)

[wieczorek1990]

I prefer the AST patch version.