On 2020-01-08 17:53, Victor Stinner wrote:

Hi,

I dislike python-config for multiple reasons

You may get the wrong information if you pick the wrong python-config script :-(

IMHO we should add a new module (problem: how should it be called? pyconfig?) which could be used using "python3 -m xxx ...". There is a similar discussion between "pip ..." and "python3 -m pip ..." commands: I understand that "python3 -m pip ..." is more reliable to know which Python will be picked, especially in a virtual environment.

Indeed. It's a bad idea to have separate executables that use/affect "the Python" or are needed to work with "the Python", but don't precisely specify "the Python". And `python -m ...` is the most sane way out of the mess.

There are two implementations: one in Python used on macOS, one in shell used on other platforms.

Moreover, if it's implemented in the stdlib, it can be implemented in Python and it should be easier to maintain than a shell script. For example, python-config has no unit test...

Could sysconfig be extended? Currently it doesn't respond to CLI flags; it should be possible to add config-like ones, e.g.: python -m sysconfig --libs python -m sysconfig --help Would that help? I must admit I don't really understand python-config. Does anyone know its purpose? History? Documentation? One thing I suspect is that it was meant as a helper for pkg-config, not to be used alone.

On 12.01.2020 19:20, musbur@posteo.org wrote:

Hi guys,

after I got the whole list into a lather about the merits of the python-config program, let me rephrase the question:

Is there a "canonical" way of automatically finding the correct include files and Python runtime library when embedding the Python interpreter, based on the current virtual environment (and not the "installed" version)? Upon reding the docs there isn't.

<full path to python executable> + '-config' Is what https://docs.python.org/3/extending/embedding.html#compiling-and-linking-und... seems to be suggesting to me. This is not applicable to Windows

And maybe there should't or cant be any. So if I want to try embedding Python under different versions I have to either install those into different directories and use python-config, or I write a trivial Python program that finds the correct values for the current environment using sysconfig and outpus those as compiler / linker flags. Easy enough, I was just surprised that no such solution was already built into the virtualenv setup mechanism

Virtualenv does create `python-config` shim in Linux.

Here's a quote from the docs """ If this procedure [using python-config] doesn’t work for you (it is not guaranteed to work for all Unix-like platforms; however, we welcome bug reports) you will have to read your system’s documentation about dynamic linking and/or examine Python’s Makefile (use sysconfig.get_makefile_filename() to find its location) and compilation options. In this case, the sysconfig module is a useful tool to programmatically extract the configuration values that you will want to combine together. For example:

...

...

...

import sysconfig sysconfig.get_config_var('LIBS') '-lpthread -ldl -lutil' sysconfig.get_config_var('LINKFORSHARED') '-Xlinker -export-dynamic' """

---

Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/364Q6EZH... Code of Conduct: http://python.org/psf/codeofconduct/

-- Regards, Ivan

On 1/13/2020 8:21 AM, Daniel Haude wrote:

Am 12.01.2020 23:39 schrieb Ivan Pozdeev via Python-Dev:

...

Virtualenv does create `python-config` shim in Linux.

Python3 doesn't. Definetely. Not on RHEL7 and Debian, that's where I tested it.

Just to ensure there's no confusion; note that "venv" and "virtualenv" are two related but different packages (venv being included in the standard library and virtualenv available on pypi). At least here on Ubuntu 18.04 with python 3.6 venv and virtualenv 16.7.9, venv does not include python-config and virtualenv does. Janzert

On 12 Jan 2020, at 16:20, musbur@posteo.org wrote:

Hi guys,

after I got the whole list into a lather about the merits of the python-config program, let me rephrase the question:

Is there a "canonical" way of automatically finding the correct include files and Python runtime library when embedding the Python interpreter, based on the current virtual environment (and not the "installed" version)? Upon reding the docs there isn't. And maybe there should't or cant be any. So if I want to try embedding Python under different versions I have to either install those into different directories and use python-config, or I write a trivial Python program that finds the correct values for the current environment using sysconfig and outpus those as compiler / linker flags. Easy enough, I was just surprised that no such solution was already built into the virtualenv setup mechanism

Here's a quote from the docs """ If this procedure [using python-config] doesn’t work for you (it is not guaranteed to work for all Unix-like platforms; however, we welcome bug reports) you will have to read your system’s documentation about dynamic linking and/or examine Python’s Makefile (use sysconfig.get_makefile_filename() to find its location) and compilation options. In this case, the sysconfig module is a useful tool to programmatically extract the configuration values that you will want to combine together. For example:

...

...

...

import sysconfig sysconfig.get_config_var('LIBS') '-lpthread -ldl -lutil' sysconfig.get_config_var('LINKFORSHARED') '-Xlinker -export-dynamic' """

I build a python C++ extension called pysvn. It's build system works by running a python program to generate a native makefile for Windows, macOS, Fedora, NetBSD etc. The code support python 2 and all the python 3's. I have all the python versions installed on my build systems side-by-side. I did not need to use venv as all the python's are installled into the systems. Maybe you can use some of the ideas from the code. See this module: https://svn.code.sf.net/p/pysvn/code/trunk/pysvn/Extension/Source/setup_conf... <https://svn.code.sf.net/p/pysvn/code/trunk/pysvn/Extension/Source/setup_conf...> Barry

_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/364Q6EZH... Code of Conduct: http://python.org/psf/codeofconduct/

Le jeu. 9 janv. 2020 à 12:11, Xavier de Gaye <xdegaye@gmail.com> a écrit :

The shell script python-config has been introduced by bpo issue 16235 named "Add python-config.sh for use during cross compilation" in order "to behave exactly the same as python-config.py except it doesn't depend on a Python interpreter" as stated in the OP. So it does not make sense to say that one may pick the wrong python-config script. Its purpose is to provide cross-compilation configuration data independently of any Python interpreter running natively on the build machine used to do the cross-compilation.

I'm thinking aloud to try to understand how it's supposed to work. Let's say that I cross-compile Python on x86-64 targeting ARM64. The build creates a ARM64 "python" program which cannot be executed on the x86-64 host. A python-config script which contains the target configuration is generated. Is the "ARM64" python-config (shell script) executed on the x86-64 host? Which build command rely on python-config? Is it to cross-compile 3rd party C extensions on the host? Victor -- Night gathers, and now my watch begins. It shall not end until my death.

Le jeu. 9 janv. 2020 à 17:19, Xavier de Gaye <xdegaye@gmail.com> a écrit :

A cross-compilation means that there is probably no build framework on the target platform and therefore the build configuration of the cross-compilation of Python is not very useful there.

Ok, so the shell script python-config is useful cross-compile things for Python on the host. But it doesn't go against the idea of providing the same feature as "python3 -m xxx ...": both can coexist ;-) Victor -- Night gathers, and now my watch begins. It shall not end until my death.