Conversation
|
PyConfig API was introduced in 3.8 (released in 2019), and we are currently requiring Python 3.6 (released in 2016). For reference, Ubuntu 20 (the oldest supported LTS) uses 3.8. |
That's up to you. My PR remains backward compatible with Python 3.6. |
@skef ? |
|
It's probably been long enough to bump to 3.8. (No guarantees that someone with more authority won't slap our wrists before it happens.) |
|
I rebased my PR to remove code for Python 3.7 and older: only keep PyConfig code for Python 3.8 and newer. I didn't test my change, I rely on the CI for that. |
|
"linux (ubuntu-20.04, Release) Expected — Waiting for status to be reported" is the CI working? I don't see a link to the CI job. |
|
Please update Python version in CMakeLists.txt |
Nah. If they wanna look they can look. |
|
At some point you gotta break from maintaining for Horse carriages and buggy wips.
|
The Py_SetProgramName() function used by fontforge is deprecated and was removed in Python 3.13 alpha 1. Replace the deprecated function with the PyConfig API. If the Python initialization fails, log an error to stderr and call exit(1). CMakeLists.txt: change Python minimum version to 3.8.
Done. |
|
@iorsh: Would you mind to review the updated PR? |
|
@skef, could you please approve CI workflows? |
|
CI is broken, issue unrelated to this PR. I'll need to take a look. |
|
@JoesCat , could you please downgrade autoconf requirement in libspiro to 2.69 (see https://github.com/fontforge/libspiro/blob/da2d627d4147e75bada0f3923c262ada81cbec76/configure.ac#L6)? |
AC_PREREQ(2.70) downgraded to 2.69 for ELN distros, as explained here: fontforge/fontforge#5404 (comment)
|
Wheels of progress are quick. Updated to 1.5 now with change added for 2.69. |
The Linux CI fails with: |
That was libspiro, I think. Try to force push to trigger CI again, linux should be good now. Mac still broken though... |
|
The CIs were stuck. I close/reopen the PR to force new CI jobs. |
I pushed an empty commit and then closed/reopened the PR, but CIs don't want to start. They are stuck at "Expected — Waiting for status to be reported" with no "Details" link. |
|
@iorsh for whatever reason the mac job is hanging before getting picked up by a server. Could the OS version be wrong/unavailable? |
|
Oh, I forgot to call PyConfig_Clear(): it's now fixed. |
|
It's working now. |
|
Thank you. |
| SetPythonProgramName("fontforge"); | ||
| PyConfig config; | ||
| PyStatus status; | ||
| PyConfig_InitPythonConfig(&config); |
There was a problem hiding this comment.
Since this is an embedded usecase, should this be PyConfig_InitIsolatedConfig instead?
There was a problem hiding this comment.
It depends on the behavior that you want. Isolated mode ignores env vars for example. I used Python mode to avoid behavior changes, only to use the new API.
There was a problem hiding this comment.
Yes, not changing the behavior in a refactor makes a lot of sense.
I think there's an argument to changing from this current behavior, too, since it doesn't make too much sense to me to prioritize the current working directory to load (say) pkg_resources over what's in the system path, yet that's what's done today. (The first entry in sys.path is the empty string, which loads from the current directory.)
Lines 293 to 295 in 9af60ed
The current behavior has shades of DLL hijacking where running the application in the wrong directory causes unintentional code execution.
There was a problem hiding this comment.
You may open a new issue since this PR is closed.
There was a problem hiding this comment.
Thank you for the encouragement. I have opened #5515.
AC_PREREQ(2.70) downgraded to 2.69 for ELN distros, as explained here: fontforge/fontforge#5404 (comment)
The Py_SetProgramName() function used by fontforge is deprecated and was removed in Python 3.13 alpha 1.
Replace the deprecated function with the PyConfig API on Python 3.8. If the Python initialization fails, log an error to stderr and call exit(1).
Type of change