[main] Split shared Python library to libpython - #894
Conversation
|
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( I do have some suggestions for making it better though... For recipe/meta.yaml:
This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/32334869920. Examine the logs at this URL for more detail. |
010b93e to
b74a768
Compare
|
Rebased after #888. Could you PTAL @conda-forge/python? :) |
|
@conda-forge-admin, please relint |
isuruf
left a comment
There was a problem hiding this comment.
libpython should be a dependency of python for python<3.15 to not break anything downstream
|
Hm. So I guess I need to switch the build order here. Conda can't figure out to build Also, quick question, I just stumbled upon https://github.com/conda-forge/libpython-feedstock/blob/main/recipe/meta.yaml (by looking through the package metadata for existing |
|
We should move feedstocks to use |
|
And repodata-patch existing users of |
This turned into a pretty big operation (and likely still contains bugs). Not sure if this is along the lines of what you had in mind. |
|
Before spending more time on this, can you confirm whether the last commit here is of the shape & kind that you had in mind @isuruf? |
|
OK, this is freshly rebased and ready now. I also improved the git history around the build order switch. PTAL @isuruf |
|
I guess we should merge conda-forge/conda-forge-repodata-patches-feedstock#1236 at the same time or before (due to the bare |
|
@isuruf, could you review here please? 🙏 |
|
Ping @isuruf. It'd be nice to be able to avoid having to keep rebasing this PR for anything that touches the build scripts (e.g. risc-v support) |
|
Thanks |
Same defect as on main, backported for consistency: the build enables -Dtpython=ON and -Dtmva-pymva=ON, and both libROOTTPython and libPyMVA link Python3::Python - an embedded CPython, not the extension-module ABI. The osx-only TPython patch rewires one of the two, so libpython is linked on every platform. Today this branch only builds 3.11-3.14, where the python package still depends on libpython and drags it in transitively, so this is a declaration fix that silences the overlinking warning rather than a functional change. It becomes load-bearing the moment 3.15 is added, since python 3.15 drops that dependency (conda-forge/python-feedstock#894). Listed in both host and run because libpython only gained a run-export on the 3.15 branch (conda-forge/python-feedstock#928). Not a pinned variant key, so no rerender is needed for it.
Same defect as on main, backported for consistency: the build enables -Dtpython=ON and -Dtmva-pymva=ON, and both libROOTTPython and libPyMVA link Python3::Python - an embedded CPython, not the extension-module ABI. The osx-only TPython patch rewires one of the two, so libpython is linked on every platform. Today this branch only builds 3.11-3.14, where the python package still depends on libpython and drags it in transitively, so this is a declaration fix that silences the overlinking warning rather than a functional change. It becomes load-bearing the moment 3.15 is added, since python 3.15 drops that dependency (conda-forge/python-feedstock#894). Listed in both host and run because libpython only gained a run-export on the 3.15 branch (conda-forge/python-feedstock#928). Not a pinned variant key, so no rerender is needed for it.
The conda build enables -Dtpython=ON and -Dtmva-pymva=ON, and both
libROOTTPython and libPyMVA link Python3::Python, i.e. an embedded
CPython rather than the extension-module ABI. Patch 0004 rewires only
TPython, and only on osx, so libpython is linked on every platform.
The 6.40.04 build already reports this:
warning Overlinking against "lib/libpython3.12.so.1.0" for
"lib/libROOTTPython.so.6.40.04"
warning Overlinking against "lib/libpython3.12.so.1.0" for
"lib/libPyMVA.so.6.40.04"
Up to 3.14 it was only a declaration problem, because the python package
depends on libpython and so dragged it in transitively. From 3.15 the
python package drops that dependency entirely
(conda-forge/python-feedstock#894), so libpython would be absent from the
host environment and find_package(Python3 COMPONENTS Development) would
fail at configure time.
Listed in both host and run: libpython only gained a run-export on the
3.15 branch (conda-forge/python-feedstock#928), so host alone is not
enough for 3.11-3.14. libpython is not a pinned variant key, so this
needs no rerender on its own.
Verified with a render; the linking result is left to CI.
Partial backport of #842, specifically 6eeda71, as suggested in #885. I also picked up another useful commit from the dev branch while rebasing. Once this PR (and a rebased #885) are merged, I'm happy to backport the pair as combined PRs to the maintenance branches.