ARM OSX Migrator

[regro-cf-autotick-bot]

This feedstock is being rebuilt as part of the ARM OSX migration.

Feel free to merge the PR if CI is all green, but please don't close it without reaching out the the ARM OSX team first at @conda-forge/help-osx-arm64.

If this PR was opened in error or needs to be updated please add the bot-rerun label to this PR. The bot will close this PR and schedule another one. If you do not have permissions to add this label, you can use the phrase code>@<space/conda-forge-admin, please rerun bot in a PR comment to have the conda-forge-admin add it for you.

_{This PR was created by the regro-cf-autotick-bot. The regro-cf-autotick-bot is a service to automatically track the dependency graph, migrate packages, and propose package version updates for conda-forge. Feel free to drop us a line if there are any issues! This PR was generated by https://github.com/regro/autotick-bot/actions/runs/1726019886, please use this URL for debugging.}

[conda-forge-linter]

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) and found it was in an excellent condition.

[hoechenberger]

Hello, I was wondering if there's any intention to get this migration done? Or will work be focused on getting Qt6 merged instead? Thank you!

[BastianZim]

I'm not a maintainer here but from what I've gathered, QT is being split up into qt-main and qt-web. Once that is finished, this package will be empty and only pull in the others so your best bet is following the work there.

[hoechenberger]

@BastianZim

I'm not a maintainer here but from what I've gathered, QT is being split up into qt-main and qt-web. Once that is finished, this package will be empty and only pull in the others so your best bet is following the work there.

Thank you for the explanation! Now I'm wondering how this relates to the work on the qt6 feedstock? Is this an entirely separate effort?

[BastianZim]

That I don't know 😄 I'd suggest asking there directly.

[ccordoba12]

Is this an entirely separate effort?

Yes, it is. And we don't understand why.

[mlondschien]

I'm not a maintainer here but from what I've gathered, QT is being split up into qt-main and qt-web. Once that is finished, this package will be empty and only pull in the others so your best bet is following the work there.

Are you suggesting that qt will never be available for osx-arm64? This would be a shame, as packages which depend on qt (and there are a few, see the graph here) will also not be able to be built for osx-arm64 before migrating their dependencies to qt-main and qt-web.

May I ask what is blocking this migration?

[hoechenberger]

I don't think that's what they meant, just that the package organization is changing and qt may just become a metapackage, no? And the new packages will of course be made available for arm64. At least that's my understanding! 😅

[BastianZim]

Yes that's correct.

Qt will be an empty package that doesn't need to be migrated anymore, it will just depend on main and web and won't do anything else. Instead, main and web will provide the functionality and will need to be available on all platforms. The bot is smart enough to know that and will update the dependency graph accordingly.

[BastianZim]

May I ask what is blocking this migration?

qt is one of the most difficult packages to migrate and requires compilation time that far exceed what the CIs here are able to provide. So every migration needs to be done manually and is incredibly difficult to program.

[hoechenberger]

requires compilation time that far exceed what the CIs here are able to provide

Would it help to purchase some additional CI resources to get the migration done more easily? We could set up a fundraiser to help purchase, say, a couple hundred hours of computational time on GH Actions or AWS or so..? I'd definitely chip in a couple dollars!

[BastianZim]

Unfortunately no, as the issue is mainly maintenance. Since conda-forge is quite prominent, the resources are generally donated by companies so that's taken care of (Although you can sponsor conda-forge here: https://numfocus.org/donate-to-conda-forge)

The problem is that every solution would have to be something that can be relied on for multiple years as otherwise, core would spend most of their time implementing new solutions which is quite difficult and time consuming. Additionally, the invocation needs to be happening automatically and without the possibility to abuse it which makes it even more difficult. AWS (And others) do offer M1s but only as a bare-metal computer so someone would need to apply updates there and manage the Mac etc. which is difficult in an open-source organisation since you cannot depend on someone being always around.

So, in short, no, money is not the issue, the issue is finding a CI provider that 1. donates the infrastructure to conda-forge (Doable) 2. that CI provider has a tool that can be integrated into PRs etc. similar to GitHub actions and Azure pieplines (Difficult, although conda-forge is currently experimenting with Woodpecker CI) and 3. that CI provider offering more than what is currently available (Very difficult as most open source plans include limits).

[mlondschien]

Why is cross compilation not possible here?

[BastianZim]

Because of the reasons I mentioned; it is very difficult and time-consuming. By splitting the packages up the compilation will be easier and quicker.

[regro-cf-autotick-bot]

I see that this PR has conflicts, and I'm the only committer. I'm going to close this PR and will make another one as appropriate. This was generated by https://github.com/regro/autotick-bot/actions/runs/1978038530