Hopefully PEP-0345 is the future of python packaging, moving away from setup.py to setup.cfg.
Some people already use PEP-0345 specification via d2to1.
My suggestion would be to support requires-dist as a replacement of requirements.in. Here is a sample from setup.cfg:
[metadata]
requires-dist =
pytz
Django
django-environ
django-allauth
django-autocomplete-light
django-bootstrap-form
django-compressor
django-libsass
django-webtest
pytest-django
It would be nice, if pip-compile could look if setup.cfg file exists and has [metadata] section in it. Then pip-compile could read list of packages from it and use instead of requirements.in.
Otherwise it could fall back to requirements.in.
sirex
All 4 comments
Given how things evolved, I will close this.
vphilippon
on 26 Mar 2018
How did things evolve? People are using setup.cfg. I am using setup.cfg. Why isn't it a good idea for pip-tools to be able to read setup.cfg? Or is it only not a good idea for pip-tools to be able to read [metadata]requires-dist from setup.cfg and other areas (eg [options]install_requires) might be a good idea?
exarkun
on 9 Jul 2019
PEP 345 defines Metadata, not putting it in setup.cfg: that鈥檚 PEP 390 which is rejected.
tl;dr: pip-tools should/may read the same things that pip reads, there is no standard source for requirements.
More:
Instead of getting distutils2 as a replacement of distutils + setuptools + pkginfo + others, with settings read from setup.cfg and features to build, package, upload, download and install distributions, the current landscape is building on other PEPs to allow many tools to coexist, operating on shared specifications and interfaces.
There are many tools to go from source dir to built wheel; some may use setup.cfg, other pyproject.toml, other a Python script, etc. Inside the wheel, the metadata file follows PEP 345, and uses a machine-readable format that鈥檚 not specifically designed to be read or edited by humans. (The wheel filename also encodes some standardized bits of info regarding compatibility.)
But this doesn鈥檛 mean that build/install instructions become different and manual for each project: PEP 517 and PEP 518 allow you to use a 芦frontend禄 tool (pip is one, but hatch or dephell or conda can also implement the interface) that knows how to install and invoke the right build tool for each project.
Different tools (twine, flit) can take the wheel and upload it to various repositories (PyPI, TestPyPI, devpi private index).
Installers such as pip know how to download distributions from repositories, read the metadata and install it as defined in PEP 376, so that run-time tools can inspect installed dependencies.
Many tools used to be able to read their config from setup.cfg, as it was a file present in many Python projects and not too hard to edit. Then many tools added support for tox.ini, for the same reasons. Now pyproject.toml is becoming a new shared config file for development tools!
At the moment, every build tool defines its own way of reading dependencies; setup.cfg[metadata] is not standard, and the pyproject.toml spec only defines build-time dependencies, not run-time. So pip-tools should read the same thing that pip reads.
merwok
on 9 Jul 2019
Thanks for the explanation.
exarkun
on 9 Jul 2019
Related issues
gwerbin
路
4Comments
nicoa
路
3Comments
marcelloromani
路
3Comments
sp-bot-tools
路
4Comments
JulienPalard
路
3Comments
Most helpful comment
PEP 345 defines Metadata, not putting it in setup.cfg: that鈥檚 PEP 390 which is rejected.
tl;dr: pip-tools should/may read the same things that pip reads, there is no standard source for requirements.
More:
Instead of getting distutils2 as a replacement of distutils + setuptools + pkginfo + others, with settings read from setup.cfg and features to build, package, upload, download and install distributions, the current landscape is building on other PEPs to allow many tools to coexist, operating on shared specifications and interfaces.
There are many tools to go from source dir to built wheel; some may use setup.cfg, other pyproject.toml, other a Python script, etc. Inside the wheel, the metadata file follows PEP 345, and uses a machine-readable format that鈥檚 not specifically designed to be read or edited by humans. (The wheel filename also encodes some standardized bits of info regarding compatibility.)
But this doesn鈥檛 mean that build/install instructions become different and manual for each project: PEP 517 and PEP 518 allow you to use a 芦frontend禄 tool (pip is one, but hatch or dephell or conda can also implement the interface) that knows how to install and invoke the right build tool for each project.
Different tools (twine, flit) can take the wheel and upload it to various repositories (PyPI, TestPyPI, devpi private index).
Installers such as pip know how to download distributions from repositories, read the metadata and install it as defined in PEP 376, so that run-time tools can inspect installed dependencies.
Many tools used to be able to read their config from setup.cfg, as it was a file present in many Python projects and not too hard to edit. Then many tools added support for tox.ini, for the same reasons. Now pyproject.toml is becoming a new shared config file for development tools!
At the moment, every build tool defines its own way of reading dependencies;
setup.cfg[metadata]is not standard, and the pyproject.toml spec only defines build-time dependencies, not run-time. So pip-tools should read the same thing that pip reads.