Tool delocate-wheel alters tag in wheel name to seemingly invalid tag/number
#214
Comments
|
Can you try setting the environment variable |
|
Which dependencies are forcing 13.6? If those are built locally then maybe set |
Thanks for the quick replies. We have already set this variable, but in the case of https://github.com/equinor/Carolina/actions/runs/8611588703/job/23599070801?pr=105 This has me a bit stumped though (why does the error indicate it needs target 14.0 ?) This does not affect macOS-14 arm64-builds where we had to specify Using the following setup works fine:
Please note that I am using the same build-files when assembling this wheel. |
|
I'll clarify that Delocate 0.11.0 has PR #198 applied which is the cause of the "error". For other devs, this was able to reveal compatibility issues unknown before the release of Delocate 0.11.0. Delocate 0.10.7 does not verify MacOS version compatibility, Delocate 0.11.0 does and will error on any detected compatibility issues. It's possible that the wheels being fixed by Delocate 0.10.7 are not compatible with MacOS 11.5 and are mislabeled (because Delocate 0.10.7 does not verify MacOS versions). It's possible libraries on a A libraries minimum MacOS version is determined from that libraries I'm not experienced enough to explain why the libraries from |
I just wanted to stress that the list provided by the tool regarding compatible tags does not include the one it ends up inserting into the filename. I've assumed this is a list of compatible tags for the wheel in question. |
|
Which tool/command gives a list of compatible tags? |
|
I realise i mistook the origin of that output, wrongfully thinking it came from Sorry about that. I still don't understand why the wheels actually work when I rename them. |
|
If the wheels fixed by Decloate in The libraries in |
The delocate package used to construct the usd-core wheel on MacOS was recently updated to 0.11.0. This version introduced new behavior that modified the name of the generated wheel, which caused issues later in our process. This behavior has affected other projects; see: matthew-brett/delocate#214. In the meantime, we pin delocate to the prior 0.10.x version to get things working again. Support for Python 3.6 was dropped in 0.10.3, so we use a "compatible release" version specifier that gets us 0.10.2 for Python 3.6 and the latest 0.10.x version (currently 0.10.7) for Python 3.7+. (Internal change: 2324479)
|
same issue here, my wheel gets renamed with an unsupported tag: macosx_13_6_x86_64 |
What was the tag you expected? And did you set |
|
I was expecting macosx_13_0_x86_64 Now if I set MACOSX_DEPLOYMENT_TARGET=13.0 I see the reason ; it flags all my python extensions modules as incompatible (but not my c++ library on which they depend): note that it does not happen on arm64 |
Was that Python installation built locally? Perhaps with |
|
no, I'm using Python from homebrew but its not even linked to Python explicitely: |
|
How does one affect the |
|
It turns out it was cmake that decided set the min osx version, I worked around it with: https://cmake.org/cmake/help/latest/variable/CMAKE_OSX_DEPLOYMENT_TARGET.html |
|
My understanding is that for any version of macos > 10, See this comment and subsequent replies for discussion. |
|
I also have this issue for the macos images in github actions (compiling c++ with clang and meson, creating module with pybind11), from what I can see: I use the macos-12 (actually macos 12.7, and here python 3.12 but 3.11 or 3.10 give the same results)
if I set MACOSX_DEPLOYMENT_TARGET=12.0 I get another error: So delocate gets the minimum version from the libc++ dylibs. The question is now, is this a bug or a feature of delocate? Or to put in multiple questions:
|
- until matthew-brett/delocate#214 is fixed
- until matthew-brett/delocate#214 is fixed
- until matthew-brett/delocate#214 is fixed
That's true by definition. The minor version increment indicates that features may be added which would be missing in previous versions.
Since macOS 11, the minor version is treated differently than previous macOS releases. As I reread pypa/packaging#578, it seems the upstream may have messed up and used Delocate does not account for this and is trying to give an accurate platform tag which isn't supported by the upstream packaging. We could complain upstream but I think it's too late and Delocate should simply map all Correct me if any of this is wrong. |
|
Rereading the posts on this issue seems to confirm my suspicions. It was an error to include the minor version number for the later versions of MacOS. |
That is right. The better fix would have been to start allowing minor versions, but there's no movement on that.
That also sounds like the right assessment. The output should be a wheel that's installable, so it must end in A prominent warning if a deployment target gets downgraded by |
|
The 2nd version number is truncated in a similar way as the third version number is truncated in macOS releases before 11. At least that's how I see it. The wheel tag is shown as Dependency version verification is already in, but you probably didn't notice it yet because it's also what caused this regression in the first place. Soon |
|
Thanks. I understand all that. My point was that this:
will be new, and it may yield wheels that will not work on 13.0 or 13.1. That requires a prominent warning I'd say. |
|
I'm not a native Mac user. I need to know more about the nature of the minor version in macOS 11+ to have an opinion on it. If it's simply a minor OS update for that release then it doesn't seem to be as big of a deal for casual deployment, tell devs to keep their OS up-to-date. On more stable systems where it does matter, I trust devs to be aware of what The upstream packagers have decided that the platform tags for macOS refer to each macOS release rather than the actual version numbers. I'd like to include exact versions in the wheel metadata whenever they allow it. Notes and advice on how one should use |
In (rare) cases, packages rely on an absurd deployment target. For example, |
|
That's a pretty good example. In that case maybe a warning for when |
I think so. However, if one were to use |
|
I expect Outside of I'd suggest continuing this discussion on #219. |
Describe the bug
Tool
delocate-wheelalters tag in wheel name to seemingly invalid tag/numberWe are using GitHub-runners to generate som large macOS wheels for repository
CarolinaTo Reproduce
The wheel before we use
delocate:Running
delocate-wheel:I see that there are dependencies that would indicate this to be set to
13_x, but as far as I can tell the wheel won't work when13_6is used. If I rename the file I can install it locally. The same is true for11_0.Wheels used/generated
carolina-1.0.16.dev3+g42cf9bc-cp311-cp311-macosx_13_6_x86_64.whl.tar.gz
carolina-1.0.16.dev2+g9c153fd-cp311-cp311-macosx_11_0_x86_64.whl.tar.gz
Platform (please complete the following information):
Additional context
Works with previous release, 0.10.7
The text was updated successfully, but these errors were encountered: