python-config.py should be part of the stdlib

[pitrou]

BPO	33439
Nosy	@warsaw, @doko42, @gpshead, @ncoghlan, @pitrou, @encukou, @nanjekyejoannah, @shihai1991, @FFY00

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2018-05-07.12:15:49.732>
labels = ['3.8', 'type-feature', 'library', 'build']
title = 'python-config.py should be part of the stdlib'
updated_at = <Date 2021-10-25.16:54:17.188>
user = 'https://github.com/pitrou'

bugs.python.org fields:

activity = <Date 2021-10-25.16:54:17.188>
actor = 'gregory.p.smith'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Build', 'Library (Lib)']
creation = <Date 2018-05-07.12:15:49.732>
creator = 'pitrou'
dependencies = []
files = []
hgrepos = []
issue_num = 33439
keywords = []
message_count = 7.0
messages = ['316264', '348546', '348558', '404883', '404901', '404930', '404985']
nosy_count = 9.0
nosy_names = ['barry', 'doko', 'gregory.p.smith', 'ncoghlan', 'pitrou', 'petr.viktorin', 'nanjekyejoannah', 'shihai1991', 'FFY00']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue33439'
versions = ['Python 3.8']

[pitrou]

Rather than (or in addition to) being a standalone script, python-config should be invokable as a stdlib module, e.g. "python -m sysconfig.config". This would prevent the risk of invoking the wrong script on PATH.

[doko42]

what are the situations where the path for python and python-config is different?

This proposal doesn't say anything how to retrieve the correct information for cross builds using this module. From my point of view, python-config should stay outside the standard library.

[shihai1991]

En, looks like just only makefile would call python-config.py.
IMHO, if no out user call this script, looks it move to stdlib would be better.

[nanjekyejoannah]

I posted on Python-dev (not sure if it will help), I wanted to do this in 2019 but looks like there is still no consensus yet.

[encukou]

It seems it could be moved to sysconfig itself -- the CLI options from python-config would fit there nicely.

[nanjekyejoannah]

Yes, this was also proposed here: https://bugs.python.org/issue11602

[gpshead]

Misc/python-config.in ultimately becomes a Python script that prints things to stdout. It isn't written to be a module as is. Any work to make it one is effectively writing entirely new code to do what it does.

To keep a single source of truth for python-config behavior instead of having two as we do today (as doko noted in bpo-16235), while still exposing the values it provides for use from Python I suggest:

1. Get rid of the Misc/python-config.in python code.
2. Use Misc/python-config.sh.in exclusively.
3. Enhancing that to be able to generate a tiny data-only sysconfig.configure module.
4. Invoke python-config.sh --generate-sysconfig-bits during build time to generate a sysconfig/configure.py.

This should reduce the maintenance burden and is kinder to cross-compiliation builds (which we generally are lousy at supporting despite their importance to the world, so our bar today is merely "not regressing").

---

All that said, in what contexts would having anything that python-config produces today be available from sysconfig be useful?

[encukou]

All that said, in what contexts would having anything that python-config produces today be available from sysconfig be useful?

In contexts where your pythonX-config command doesn't match your Python. For example, in a venv.