🛠 Refactored setup.py to setup.cfg

[k4black]

Propose

Use setup.cfg for static metadata

---

Motivation

According to packaging.python.org/en/latest/tutorials/packaging-projects/

Static metadata (setup.cfg) should be preferred

Because is:

guaranteed to be the same every time. This is simpler, easier to read, and avoids many common errors, like encoding errors.

ups: PEP 621 recommend to use pyproject.toml for static metadata, however it's not well supported by setup tools for now; thats why I suggest to use setup.cfg as a transitional format from dynamic to a static metadata

What was done

Perform a small refactor of setup.py file to move all the static metadata to setup.cfg

Note

Dummy setup.py file was saved for backward compatibility and to allow install pkg in dev mode (pip install -e .)

[Kludex]

I use this format for my personal projects, but this needs discussion. It's a decision that may impact other encode projects.

I recommend starting a discussion on our Gitter first.

[k4black]

Technically, this refactor should influence only the style. (and disable ancient versions of setuptools for build this project)
From the point of style-unification of projects in the encode - I totally agree with you, so I'm going to Gitter.

[aminalaee]

Just to throw another idea, why not use pyproject.toml?

[k4black]

Yep, PEP 621 recommend to do so, however it's not fully supported by setuptools for now (see pypa/setuptools#1688 )

[agronholm]

Even setup.py is redundant in a pure Python project like this. The last reason why it was still needed was editable installs but pip 21.3 rectified that. As for PEP 621 support, I would love to add that support to setuptools but alas, my TODO list is way too long already for that to happen in a reasonable timeframe.

[k4black]

@agronholm That's why I suggest current (PR) setup; with setup.cfg as a transitional format and dummy setup.py to add some backward compatibility
If any refactoring will be approved Im ready to open such PR in encode projects to support uni-style

[Kludex]

We should probably wait for pypa/setuptools#2924 . I've subscribed to that PR some days ago, and the development is quite active lately.

[Kludex]

This should be watched instead: pypa/setuptools#2970

[tomchristie]

This is an interesting idea yes.
Generally preferable to have declarative rather than imperative configuration.

However, consistency across the encode codebases is also pretty important here, as is minimising code and tooling churn.

I'd like to close this off for now, but am open to discussion around if we'd want to switch styles across encode.