Switch to PEP517 packaging

MichaelKim0407 / flake8-use-fstring

MIT License

51 stars 7 forks source link

Switch to PEP517 packaging #24

Closed akx closed 2 years ago

akx commented 2 years ago

This PR:

switches setup.py out for pyproject.toml and a declarative setup.cfg (and build instead of setup.py), for the more modern packaging experience
updates some GitHub Action versions for newer ones (and makes Coveralls non-critical, since it won't work in a fork anyway)

You can see CI passing here on my fork should you need to.

MichaelKim0407 commented 2 years ago

Hi, thanks for the PR. However, I am quite hesitant to merge it. Can you please explain your rationale behind this change?

I gave PEP517 a quick look, but what are the benefits for this project exactly?

Given the relatively small activity on this project since its beginning, I'd rather adopt the policy of if it ain't broke, don't fix it. Also I'm not familiar with this new technology so this will be an extra maintenance cost for me.

akx commented 2 years ago

The Python ecosystem at large is (slowly, yes) moving towards PEP517-style packaging. One major benefit is there's no longer an imperative setup.py that could technically speaking run any arbitrary code; another is that you don't need to know that sdist and bdist_wheel and friends are things; just build and the machinery takes care of things.

This new system is what the Packaging tutorial recommends these days.

MichaelKim0407 commented 2 years ago

Yes, I understand that it's a new fancy thing for the Python community. And like I said, I looked briefly at PEP517 and the rationales there.

I am asking how specifically it can benefit the development and maintenance of this project, when the current setup is already working as intended.