Add `sys.runtime_library`

[FFY00]

Feature or enhancement

Proposal:

It would be useful to expose the runtime library path, if any, as a sys module attribute.

This is already implemented for getpath, we can easily make this information also available in sys.

cpython/Modules/getpath.c

Lines 805 to 829 in 10ee2d9

	/* Add the runtime library's path to the dict */
	static int
	library_to_dict(PyObject *dict, const char *key)
	{
	/* macOS framework builds do not link against a libpython dynamic library, but
	instead link against a macOS Framework. */
	#if defined(Py_ENABLE_SHARED) || defined(WITH_NEXT_FRAMEWORK)
	#ifdef MS_WINDOWS
	extern HMODULE PyWin_DLLhModule;
	if (PyWin_DLLhModule) {
	return winmodule_to_dict(dict, key, PyWin_DLLhModule);
	}
	#endif
	#if HAVE_DLADDR
	Dl_info libpython_info;
	if (dladdr(&Py_Initialize, &libpython_info) && libpython_info.dli_fname) {
	return decode_to_dict(dict, key, libpython_info.dli_fname);
	}
	#endif
	#endif
	return PyDict_SetItemString(dict, key, Py_None) == 0;
	}

I'm proposing sys, as I think that's what makes the most logical sense, but people are not too keen on it, we could add it to sysconfig instead.

Has this already been discussed elsewhere?

No response given

Links to previous discussion of this feature:

No response

[vstinner]

What is the runtime library path?

[FFY00]

It's libpython. If it's dynamically linked, sys.runtime_library will contain its path, if it's statically linked, it will be None.

[ncoghlan]

When Python is built as a shared library, the path to that library.

$ ldd `which python3`
        linux-vdso.so.1 (0x00007ffc3ddbe000)
        libpython3.12.so.1.0 => /lib64/libpython3.12.so.1.0 (0x00007fe292720000)  # This path
        libc.so.6 => /lib64/libc.so.6 (0x00007fe29252f000)
        libm.so.6 => /lib64/libm.so.6 (0x00007fe29244b000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fe292d06000)

It's the value provided for the library variable when running https://github.com/python/cpython/blob/main/Modules/getpath.py

It's very much a CPython implementation detail though, since even CPython doesn't define it when statically linked. (The same is also true of sys.dllhandle, but that ship has already sailed).

Checking what setuptools does, the current incantation to get that info would be:

$ python3 -c "from sysconfig import get_config_var as gcv; import os.path; print(os.path.join(gcv('base'), gcv('platlibdir'), gcv('LDLIBRARY')))"
/usr/lib64/libpython3.12.so

[zooba]

What is it useful for? And why is calculating it from sysconfig (mixed with sys.prefix if you want relocatability) not sufficient?

In getpath, we use it because Windows historically would resolve the stdlib against the DLL, and later we resolve ._pth files from it,¹ but that's very much internal implementation.

sys.dllhandle probably shouldn't have been added, as GetModuleHandle(dll_name) is a perfectly fine way to get the same information. It's done now, so we can't take it away, but we don't have to continue making the same mistake.

Footnotes

1. For security reasons. It allows to control attackers that manage to LoadLibrary the DLL, or to simplify controlling your host app when you have multiple executables. ↩

[gpshead]

What are the use cases for exposing this more widely?