Introduce setup.cfg
sebastianneubauer opened this issue · 18 comments
The best development in the python packaging field in the last years is the introduction of the setup.cfg:
- declarative description
- simple to read
- easy to diff
It reduces the need for error prone, cargo cult boilerplate code in the setup.py.
A nice setup.py should look like this (if it should exist at all):
from setuptools import setup
if __name__ == "__main__":
setup()
IMHO, the rest should be declaratively described without arbitrary code execution in the setup.cfg
In fact the best options is pyproject.toml
specified by https://www.python.org/dev/peps/pep-0518/ and https://www.python.org/dev/peps/pep-0517/
But that PEPs are still work in progress, that may deprecate setup.py and setup.cfg to use tools like flit
(as described in PEP 517) or Poet.
I hope future gives us a built-in package manager python -m package
or something like this, plugin based and able to read those files and perform all package related operations in one place.
I prefer this method, personally. Can you show me what this repo would look like migrated to setup.cfg
and the implications thereof?
@rochacbruno so those only work when people have new setuptools, right?
@kennethreitz yes1 New in 30.3.0 (8 Dec 2016)
anyway, I think this repo can be splitted in different folders - simple
- setup_cfg
- reqs_parsing
etc... this way there will be options for every taste
I prefer "one obvious way to do it".
I think setup.py
is still the one obvious way to do it — but I'll stew on this. Let's look at the setuptools download spread from the last month.
I don't have data on versions of setuptools installed (yet), but here's a breakdown of versions of Python used by setuptools
installers in the last month:
{
"data": {
"package": {
"recentPythonVersionSpread": [
{
"version": "2.7",
"downloads": 9332151
},
{
"version": null,
"downloads": 1330229
},
{
"version": "3.5",
"downloads": 674032
},
{
"version": "2.6",
"downloads": 562136
},
{
"version": "3.4",
"downloads": 447792
},
{
"version": "3.6",
"downloads": 437776
},
{
"version": "3.3",
"downloads": 33177
},
{
"version": "3.2",
"downloads": 22857
},
{
"version": "3.7",
"downloads": 7381
},
{
"version": "2.4",
"downloads": 677
},
{
"version": "1.17",
"downloads": 302
},
{
"version": "2.5",
"downloads": 42
},
{
"version": "2.8",
"downloads": 12
},
{
"version": "3.1",
"downloads": 5
},
{
"version": "3.0",
"downloads": 3
}
]
}
}
}
Not sure if that sheds any light on this at all
Let's get a version spread of download numbers from this month for setuptools
.
$ pypinfo setuptools version
version download_count
------- --------------
36.2.7 8304216
36.3.0 910593
33.1.1 810162
36.2.5 464626
36.2.6 448658
32.1.0 326491
32.2.0 315528
20.2.2 235684
5.4.1 209399
24.1.0 85234
18.0.1 83035
5.8 63331
30.0.0 52526
34.1.0 49220
36.0.1 44332
35.0.2 41564
36.2.4 27837
20.1.1 26429
21.0.0 22440
34.3.3 17799
Hmmm, i don't know if that's good enough for me.
Same doesn't apply here, I'm afraid :)
https://github.com/KOLANICH/bind.py
https://github.com/KOLANICH/RichConsole
https://github.com/KOLANICH/HDDModelDecoder.py
https://github.com/KOLANICH/NoSuspend.py
are also examples of projects using cfg.
-1 to setup.cfg, it'll be deprecated soon anyway
I personally include __requires__ = ('setuptools >=36.6.0', )
and newer versions of setuptools do the check for me. And then it is possible to use setup.cfg
.
@rochacbruno @ofek those PEPs are about build system requirements aka setup_requires =
, not whole setup.cfg
,as far as I can tell.