Add a libpython3.dylib to support ABI3 applications

[isuruf]

Note that this is not for extensions like numpy. It is for executbales like lldb.

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

See conda-forge/lldb-feedstock#110. cc @h-vetinari

[conda-forge-admin]

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 (recipe/meta.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe/meta.yaml:

• ℹ️ The recipe is not parsable by parser conda-souschef (grayskull). This parser is not currently used by conda-forge, but may be in the future. We are collecting information to see which recipes are compatible with grayskull.
• ℹ️ The recipe is not parsable by parser conda-recipe-manager. The recipe can only be automatically migrated to the new v1 format if it is parseable by conda-recipe-manager.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/33337695447. Examine the logs at this URL for more detail.}

[h-vetinari]

Thanks, this LGTM! Once this is approved/merged, we're gonna need this on all the maintenance branches too

[isuruf]

We need to figure out how to port it to dev given #842

[h-vetinari]

We need to figure out how to port it to dev given #842

I was mainly concerned with needing this for python_min and then the intervening versions (as python_min climbs over time); 3.15 has more time, as far as I'm concerned. 🙃

[isuruf]

I was mainly concerned with needing this for python_min and then the intervening versions (as python_min climbs over time); 3.15 has more time, as far as I'm concerned. 🙃

You need libpython3.so at runtime of lldb, so it needs to be present for 3.15 too. However since there's a new libpython with 3.15, just installing python is not enough for a lldb compiled with 3.11

[h-vetinari]

You need libpython3.so at runtime of lldb, so it needs to be present for 3.15 too.

Of course. I just meant that 3.15 only goes GA in October.

[isuruf]

I just meant that 3.15 only goes GA in October.

Yes, but adding a feature to refactor in October seems bad. We should port libpython output to older python versions too (but make it a dependency of python unlike 3.15)

[h-vetinari]

I'm not saying we should leave it in a broken state; just that we'd have 3 months to fix it, whereas for the other python versions it would be useful right away

[isuruf]

I really don't want to put libpython3.dylib in python and in three months move it into libpython. Can you send a PR to add libpython to main?

[h-vetinari]

Can you send a PR to add libpython to main?

Here's #894

[h-vetinari]

Thanks for merging #894. Would you like to rebase this PR yourself, or should I do it? My attempt in #902 looks as follows: dae4337

It wasn't enough to get CI to pass though, so I imagine this will take a bit more work.

[conda-forge-admin]

Hi! This is the friendly conda-forge automerge bot!

I considered the following status checks when analyzing this PR:

• linter: passed
• azure: failed
• github-actions: passed

Thus the PR was not passing and not merged.

[h-vetinari]

@isuruf, I found the fix, which isn't too complicated/intrusive IMO. Could you PTAL?

[isuruf]

Thanks

[h-vetinari]

FWIW, I just figured out that libpython3.so is not useable for this purpose, because it's essentially completely empty: python/cpython#104612. There's a so-far unmerged PR that fixes this with a patchelf-based approach. We could backport that commit. Or figure out an equivalent to the macOS post-install approach.