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?

[FFY00]

I think for now we can get away with just exposing it, or the whole getpath dictionary, as a private sysconfig attribute. We can revisit exposing it publicly if a strong enough need presents itself.

[zooba]

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

This is the particular line we're asking you to expand on. Yes, it's very simple to do it, and there are ways to get away with it, but the only rationale you've given is "it would be useful" - we're asking why it would be useful.

[FFY00]

To be completely honest, I don't recall what exactly triggered me to open this issue, but I have on a number of occasions wanted access to this value. So, I won't fight on this. I think exposing it as a private sysconfig attribute, at least, is worthwhile. We could revisit the original proposal later, if we find a more concrete demonstrable need.

[FFY00]

Closing as not planned for now.