PBR/distutils2 with pep517 Support Was: Conditionless setup.py
Am 25.08.2017 um 15:00 schrieb Paul Moore:
One thought - are the PBR and/or distutils2 teams looking at providing PEP 517 support? Assuming they are, have they had a change to review the PEP to ensure it suits their needs? And if they aren't, what is it about the PEP that makes them unwilling to do so?
Hi Paul, I think this is a very good question! I started a new thread to make this more visible. Are there PBR/distutils2 hackers on this list here? If yes: Do you support this pep? If no: where can you meet PBR/distutils2 hackers? Regards, Thomas Güttler -- Thomas Guettler http://www.thomas-guettler.de/
On 2017-08-28 13:05:07 +0200 (+0200), Thomas Güttler wrote: [...]
Are there PBR/distutils2 hackers on this list here?
If yes: Do you support this pep?
If no: where can you meet PBR/distutils2 hackers?
See: https://mail.python.org/pipermail/distutils-sig/2017-August/031315.html -- Jeremy Stanley
I've thought for ages that we could transition to a more sane system by convention: "your setup.py, after being imported, will have a "setup_params" attribute that is a dict that can be passed to setup()." So tools that want metadata, etc. without actually running an install could do; import setup name = setup.setup_params['name'] requirements = setup.setup_params['install_requires'] etc... i.e -- it does need to run the code in setup.py, but it does NOT need to run setup install, or build, or whatever else. A typical simple setup.py with static meta-data would be: from setuptools import setup setup_params = {name:'sample', version:'1.2.0', description:'A sample Python project', url:'https://github.com/pypa/sampleproject', author:'The Python Packaging Authority', license:'MIT', packages:['the_package'], install_requires=['peppercorn'], ... } setup(**setup_params) But a setup.py could still have arbitrary code to build up the dict of parameters if need be. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
Imo PBR is entirely a setuptools creature, without special concerns to operate in pep517 land. If I were them I'd rewrite it to not require setup.py and call that pbr2. On Mon, Aug 28, 2017, 12:44 Chris Barker <chris.barker@noaa.gov> wrote:
I've thought for ages that we could transition to a more sane system by convention:
"your setup.py, after being imported, will have a "setup_params" attribute that is a dict that can be passed to setup()."
So tools that want metadata, etc. without actually running an install could do;
import setup
name = setup.setup_params['name'] requirements = setup.setup_params['install_requires']
etc...
i.e -- it does need to run the code in setup.py, but it does NOT need to run setup install, or build, or whatever else.
A typical simple setup.py with static meta-data would be:
from setuptools import setup
setup_params = {name:'sample', version:'1.2.0', description:'A sample Python project', url:'https://github.com/pypa/sampleproject', author:'The Python Packaging Authority', license:'MIT', packages:['the_package'], install_requires=['peppercorn'], ... }
setup(**setup_params)
But a setup.py could still have arbitrary code to build up the dict of parameters if need be.
-CHB
--
Christopher Barker, Ph.D. Oceanographer
Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
On 2017-08-28 17:48:40 +0000 (+0000), Daniel Holth wrote:
Imo PBR is entirely a setuptools creature, without special concerns to operate in pep517 land. If I were them I'd rewrite it to not require setup.py and call that pbr2. [...]
While it's true that PBR relies on setuptools entrypoints _today_, the expectation is that it will also grow a PEP 517 build-system.build-backend compliant interface once the spec is officially approved. At least one problem with "just rewrite it" is that we expect to support people using old (pre-517) versions of pip for years to come, so will likely end up with some sort of hybrid implementation for as long as backwards compatibility needs to be maintained. It may also end up coupled with some manner of pre-build wrapper to consume/transform existing static metadata and emit a suitable pyproject.toml file, though that's for social reasons as much as anything. -- Jeremy Stanley
participants (4)
-
Chris Barker -
Daniel Holth -
Jeremy Stanley -
Thomas Güttler