python: fix Py_SetPythonHome deprecated API for newer versions

[r3yc0n1c]

Your checklist for this pull request

• I've read the guidelines for contributing to this repository
• I made sure to follow the project's coding style
• I've updated the documentation with the relevant information (if needed)

Detailed description
Prevent Deprecated API call since Python 3.11:

https://docs.python.org/3/c-api/init.html#c.Py_SetPythonHome
https://docs.python.org/3/c-api/init_config.html#init-config

Test plan (required)
Build test for newer versions ( > 3.11 ) of Python

Closing issues
closes #3214

[XVilka]

/Users/runner/work/cutter/cutter/src/common/PythonManager.cpp:67:5: error: unknown type name 'PyConfig'; did you mean 'RzConfig'?
    PyConfig config;
    ^~~~~~~~
    RzConfig
/Users/runner/work/cutter/cutter/build/Rizin-prefix/include/librz/rz_config.h:58:3: note: 'RzConfig' declared here
} RzConfig;
  ^
/Users/runner/work/cutter/cutter/src/common/PythonManager.cpp:68:5: error: use of undeclared identifier 'PyConfig_InitPythonConfig'
    PyConfig_InitPythonConfig(&config);
    ^
/Users/runner/work/cutter/cutter/src/common/PythonManager.cpp:72:50: error: no member named 'home' in 'rz_config_t'
        PyConfig_SetBytesString(&config, &config.home, customPythonHome);
                                          ~~~~~~ ^
/Users/runner/work/cutter/cutter/src/common/PythonManager.cpp:93:30: error: use of undeclared identifier 'config'
    Py_InitializeFromConfig(&config);
                             ^
/Users/runner/work/cutter/cutter/src/common/PythonManager.cpp:101:21: error: use of undeclared identifier 'config'
    PyConfig_Clear(&config);
                    ^

https://github.com/rizinorg/cutter/actions/runs/8408745952/job/23025329200?pr=3322#step:7:4826

[karliss]

Test plan (required)
Build test for newer versions ( > 3.11 ) of Python

This issue needs a better test plan than that. For issue like this the code changes is the easy part, properly testing it ensure it works correctly is the meat of it.

On what systems with what python versions and what Cutter build configurations did you try?

How did you test that the code for changing pythonhome is actually functioning correctly? Since this is optional config (from Pyhthon perspective, not necessarily optional for all usecases) , just having it compile and even Cutter open doesn't automatically prove that the change is correct.

I might have been less strict on this if the new API was a drop in replacement of one function requiring only very localized changes, but in this case it also changes the overall sequence of how Python is initialized.

[r3yc0n1c]

I used Ubuntu 18.04 with Python 3.11. I had multiple python versions (3.8 (system), 3.9, 3.10) with pyenv.

While testing with multiple versions I faced the Shiboken2 configuration error and when I included the <Python.h> header I got these:

Now, I switched to Ubuntu 22.04 but the configuration error still persists.

[0pendev]

Hi everyone,

Interested in this merge for packaging reasons 😄

I used Ubuntu 18.04 with Python 3.11. I had multiple python versions (3.8 (system), 3.9, 3.10) with pyenv.

While testing with multiple versions I faced the Shiboken2 configuration error and when I included the <Python.h> header I got these:

Now, I switched to Ubuntu 22.04 but the configuration error still persists.

The error is weird here. It looks like shibokken is defining structs for compatibility reasons (files prepended with 37) but you are using python38 and it redefines the struct again. How are you including those headers ?

[0pendev]

Looking at the API and ABI versioning documentation, I would suggest the following:

Suggested change

	#if (PY_MAJOR_VERSION <= 3) && (PY_MICRO_VERSION < 11)
	#if (PY_MAJOR_VERSION == 3) && (PY_MINOR_VERSION < 11)

[0pendev]

Hey @r3yc0n1c. Might have an answer to your problem.
So the cutter project defines Py_LIMITED_API in PythonAPI.h.

The problem is that shibokken redefines structs and functions already defined if this macro is set:

So I see two possible fixes:

• remove the definition in PythonAPI.h because even if it is there the project still manually checks for versioning later on
• open an issue on shiboken2

[r3yc0n1c]

Hey @r3yc0n1c. Might have an answer to your problem. So the cutter project defines Py_LIMITED_API in PythonAPI.h.

The problem is that shibokken redefines structs and functions already defined if this macro is set:

So I see two possible fixes:

• remove the definition in PythonAPI.h because even if it is there the project still manually checks for versioning later on
• open an issue on shiboken2

yeah... I was also looking into possible fixes for this... let's discuss it further on Mattermost