PKG-17802 — Python 3.15.0rc2 - #257
Conversation
Remap vs conda-forge: add 0020/0024-pid_t/0026-GIL-win/0027 unixy Windows; keep AR 0023 branding; move zlib-ng to 0028 and xxlimited to 0029.
Bump rc1→rc2 + sha256. Install Windows stdlib/headers to lib\python and include\python (0027 getpath). Drop sitecustomize python3.1 path (conda#10969). CBC zip-clobber python/numpy/is_freethreading/is_python_min so PY_VER=3.15. Keep gil_type.
Linter cannot expand this recipe; skip is by design (same as prior py315 graphs).
| - patches/0017-Do-not-pass-g-to-GCC-when-not-Py_DEBUG.patch | ||
| - patches/0018-Unvendor-expat.patch | ||
| - patches/0019-Remove-unused-readelf.patch | ||
| - patches/0020-Don-t-checksharedmods-if-cross-compiling.patch |
There was a problem hiding this comment.
Keeping it here because it's always confusing where 0020 is. But we can comment it out.
Ignore cxx run_exports on libpython/libpython-static (unix overdepending). Skip python-jit when freethreading=yes. Skip parsing_jinja_failure like #257. Drop dead skip_compile_pyc cross-compile selector.
| :: Populate the libs directory (and lib, matching CF unixy layout) | ||
| for %%x in (lib libs) do ( | ||
| if not exist %PREFIX%\%%x mkdir %PREFIX%\%%x | ||
| if exist %SRC_DIR%\PCbuild\%BUILD_PATH%\python%VERNODOTS%%THREAD%%_D%.lib copy /Y %SRC_DIR%\PCbuild\%BUILD_PATH%\python%VERNODOTS%%THREAD%%_D%.lib %PREFIX%\%%x\ | ||
| if errorlevel 1 exit 1 | ||
| if exist %SRC_DIR%\PCbuild\%BUILD_PATH%\python3%THREAD%%_D%.lib copy /Y %SRC_DIR%\PCbuild\%BUILD_PATH%\python3%THREAD%%_D%.lib %PREFIX%\%%x\ | ||
| if errorlevel 1 exit 1 | ||
| if exist %SRC_DIR%\PCbuild\%BUILD_PATH%\_tkinter%_D%.lib copy /Y %SRC_DIR%\PCbuild\%BUILD_PATH%\_tkinter%_D%.lib %PREFIX%\%%x\ | ||
| if errorlevel 1 exit 1 | ||
| ) |
There was a problem hiding this comment.
Isn't the point of the unixy layout that there is no libs any more as it is now lib?
And, noting the other changes, I'm not seeing lib\python, only (the equivalent of) %PREFIX%\lib.
I think you've conflated the previous layout with the new layout and tried to use both.
There was a problem hiding this comment.
CF still iterates both https://github.com/conda-forge/python-feedstock/blob/main/recipe/build_base.bat#L177
There was a problem hiding this comment.
Oh wait. These are the import libraries for Python and Tk which want to be in lib (or libs?) for the compiler to find at build time as opposed to the executable parts that python is going to be looking for at runtime.
It's all a bit squirrelly.
There was a problem hiding this comment.
They drop it in the dev branch https://github.com/conda-forge/python-feedstock/blob/dev/recipe/build_base.bat#L175-L182
Should we be following that instead of main?
There was a problem hiding this comment.
Yeah, I should copy import libs only to %PREFIX%\lib\ to match CF.
And replace libs\python to lib\python in tests on Windows
There was a problem hiding this comment.
They drop it in the
devbranch conda-forge/python-feedstock@dev/recipe/build_base.bat#L175-L182Should we be following that instead of
main?
It was 2 months ago for rc1 https://github.com/conda-forge/python-feedstock/blob/dev/recipe/meta.yaml#L2
I'm already confused with all of that renaming/replacing/droping lib here, libs there....
There was a problem hiding this comment.
For the record.
We already have the right Windows layout:
stdlib==lib\python\- import
.libgoes to →%PREFIX%\lib\and we testlib\python315.libin the test section.
There was a problem hiding this comment.
For the record:
Python 3.15 rc2 artifact check revealed that Unix looks solid, but we had a win-64 problem.
Setuptools, distutils, meson-python, and Python <3.11 unconditionally look for import libs in {exec_prefix}\libs, and conda-forge nuked that directory.
CF ships both again —we should too. C-extension packages downstream depend on it.
I reverted that change to restore the libs\ copy while keeping the lib\ stdlib fix.
Everything else lines up or is an intentional AR choice. #256 will add the libpython3.dylib symlink on macOS while we're at it.
There was a problem hiding this comment.
@cbouss
Reference URLs — Python 3.15 rc2 AR vs CF alignment
- CFEP-27 (https://github.com/conda-forge/cfep/blob/main/cfep-27.md) — Conda-Forge Enhancement Proposal on _sysconfigdata naming convention and sysroot handling across platforms.
- CFEP PR Updates version to 3.9.13 #66 (Update CFEP 27 for libs conda-forge/cfep#66) — Discussion and refinement of the sysconfig data naming standard.
- conda-forge python-feedstock PR keep import libraries in libs to help meson and other build systems conda-forge/python-feedstock#918 review (keep import libraries in libs to help meson and other build systems conda-forge/python-feedstock#918 (review)) — CF maintainer's rationale on _sysconfigdata file naming decisions.
- conda-forge docs PR #2925 (https://github.com/conda-forge/conda-forge.github.io/pull/2925/changes) — Documentation clarification on python_rc label vs channel distinction.
- distutils build_ext.py (https://github.com/pypa/distutils/blob/main/distutils/command/build_ext.py#L231-L237) — Hardcoded unconditional resolution of {exec_prefix}\libs for import libs on Windows (lines 231–237).
- setuptools vendored build_ext.py (https://github.com/pypa/setuptools/blob/main/setuptools/_distutils/command/build_ext.py#L237) — Setuptools' copy of the same unconditional libs\ path resolution logic.
| # Workaround for https://github.com/conda/conda/issues/10969 | ||
| dirs_to_add.append(os.path.join(sys.prefix, 'lib', f'python3.1', 'site-packages')) |
Unixy 0027 layout matches conda-forge; stdlib stays in lib\python\.
|
@ifitchet I aligned more lines with CF :) |
distutils/setuptools build_ext hardcodes exec_prefix\libs on nt; meson cannot query the import-lib dir (PEP 739 oversight). Matches conda-forge PR 918 and the published rc2 win-64 artifacts (lib\ + libs\).
Upstream Makefile only creates libpython3.so on linux; macOS has no rule. Build the re-export dylib like CF install_shared.sh and assert it in tests.
|
AR python-feedstock historical commit (db61f52) — Original introduction of _sysconfigdata_x86_64_conda_cos6_linux_gnu.py naming in our recipe. We should get rid of it too and align with CF and compilers https://github.com/AnacondaRecipes/ctng-compiler-activation-feedstock/blob/main/recipe/conda_build_config.yaml#L119 |
The cosN-named file was a 2020-era shim (db61f52) for CDT compilers. Current gcc_linux-64 15.2.0 activation defaults to the modern _sysconfigdata_x86_64_conda_linux_gnu name, same as conda-forge.
2 participants
Destination channel: ad-testing/label/py315
Links
Explanation of changes:
sha2568d93af5e…).v3.15.0rc2(0020, 0024 pid_t, 0027 unixy Windows, 0028 zlib-ng, 0029 xxlimited; keep AR 0023 branding).lib\python,include\python).sitecustomize.pypython3.1path (conda#10969). It was a leftover we were not aware.python/numpy/is_freethreading/is_python_minsoPY_VER=3.15. Keepgil_type.0004extra file from PKG-17264 — Python 3.15.0rc1 (master-replay) #249; keep getpath only. It aligns with CFNotes:
ad-testing/label/py315. Do not upload topkgs/main.