PEP-0345 support

[sirex]

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.

[vphilippon]

Given how things evolved, I will close this.

[exarkun]

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?

[merwok]

PEP 345 defines Metadata, not putting it in setup.cfg: that’s 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’s 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’t 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.

[exarkun]

Thanks for the explanation.