disable propagation of PY_LIMITED_API to dependent targets

[looooo]

Checklist

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

[conda-forge-webservices[bot]]

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.

[looooo]

232

[hmaarrfk]

I'm not too sure if removing this file would break things:

  cp -v ./tests/pysidetest/testbinding.abi3.so ${SP_DIR}

are you able to use the limited ABI in your package? it seems that more and more packages are moving in that direction. May I ask if there is 1 particular function that needs it or is it more wide spread?

[looooo]

are you able to use the limited ABI in your package?

not yet. Also I don't think the transition will happen for the next release.

May I ask if there is 1 particular function that needs it or is it more wide spread?

From looking at the build-errors it seems like it's used in more than one place.

I am wondering why the LIMITED_API is propragated to downstream packages? Is there any reason for this?

[conda-forge-webservices[bot]]

Hi! This is the friendly automated conda-forge-linting service.

I was trying to look for recipes to lint for you, but it appears we have a merge conflict. Please try to merge or rebase with the base branch to resolve this conflict.

Please ping the 'conda-forge/core' team (using the @ notation in a comment) if you believe this is a bug.

[conda-forge-webservices[bot]]

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.

[looooo]

this addition changes in ${PREFIX}/lib/cmake/Shiboken6/Shiboken6Targets.cmake this:

set_target_properties(Shiboken6::libshiboken PROPERTIES
  INTERFACE_COMPILE_DEFINITIONS "Py_LIMITED_API=0x03060000;NDEBUG"
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include/shiboken6"
)

to

set_target_properties(Shiboken6::libshiboken PROPERTIES
  INTERFACE_COMPILE_DEFINITIONS "NDEBUG"
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include/shiboken6"
)

In my mind Pyside6/Shiboken6 should not propagate the PY_LIMITED_API to downstram packages. At least it makes no sense for me.

[hmaarrfk]

it may be appropriate for us to patch that out and simultaneously issue a bug report upstream.

[hmaarrfk]

ps it may have been due to https://bugreports.qt.io/browse/PYSIDE-1775?jql=text+%7E+%22PY_LIMITED_API%22

i think it would be good if you could open an issue upstream, and we can "track it" even if for years to come...

[looooo]

done: https://bugreports.qt.io/browse/PYSIDE-2822

and it is closed already. I guesss it's good practice to move to PY_LIMITED_API, but forcing downstream projects to do so, is not the right way (in my opinion)