Merge qt6 into main

[JarrettSJohnson]

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.

@h-vetinari , was this what you proposed (merging qt6 into main)?

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-webservice.

It appears you are making a pull request from a branch in your feedstock and not a fork. This procedure will generate a separate build for each push to the branch and is thus not allowed. See our documentation for more details.

Please close this pull request and remake it from a fork of this feedstock.

Have a great day!

[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/21886194637. Examine the logs at this URL for more detail.}

[h-vetinari]

@h-vetinari , was this what you proposed (merging qt6 into main)?

Indeed, that's what I meant, thanks! We can then create a qt5 branch off of the state of main before this PR (i.e. 6c8863a)

[JarrettSJohnson]

Indeed, that's what I meant, thanks! We can then create a qt5 branch off of the state of main before this PR (i.e. 6c8863a)

Sounds good. I don't have maintenance powers for this feedstock. Are you (or anyone else) able to take care of that?

[ccordoba12]

Moving this to draft to give people a bit more time to test and report errors with the new packages (see #163 for instance).

[ccordoba12]

On a second thought, I (as one of feedstock maintainers) would prefer to maintain main and qt6 as separate branches. That's because:

• Many other Qt-related feedstocks also have separate branches and (as far as I know) they haven't replaced main by qt6 yet.
• Spyder still uses PyQt5, and we'll continue to use it until there are WebEngine packages for Qt6 in conda-forge. So, most probably it'll be necessary to maintain it for a bit longer (I can take care of that). But this merge would make that not feasible.

[ccordoba12]

Thanks for understanding @JarrettSJohnson!

[h-vetinari]

But this merge would make that not feasible.

That's incorrect. What is on main currently would then become a branch called qt5, and both branches (main and qt5) could be maintained concurrently (just as main and qt6 have been); the only thing that would change is which one is the "default". That's what we did for qt-main.

Now, you can still argue of course that qt6 is not ready to be the default (e.g. for pyqt, v6 support is still relatively recent), but merging qt6 into main does not mean that pyqt 5.x couldn't be maintained anymore.

[ccordoba12]

That's incorrect. What is on main currently would then become a branch called qt5, and both branches (main and qt5) could be maintained concurrently (just as main and qt6 have been); the only thing that would change is which one is the "default".

Sure, that would work too but no one suggested to do it. So, I thought qt6 will replace main and that was it.

That's what we did for qt-main.

Sorry, I missed that one.

Now, you can still argue of course that qt6 is not ready to be the default

That's what I did (i.e. lack of WebEngine packages). But if a qt5 branch is created first then I have no problem with merging this one.

[h-vetinari]

Sure, that would work too but no one suggested to do it.

I did suggest that :)

We can then create a qt5 branch off of the state of main before this PR (i.e. 6c8863a)

---

But if a qt5 branch is created first then I have no problem with merging this one.

Sounds good! Should we just reopen this PR? In any case, I can offer to help with the necessary git resp. feedstock operations.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-webservice.

It appears you are making a pull request from a branch in your feedstock and not a fork. This procedure will generate a separate build for each push to the branch and is thus not allowed. See our documentation for more details.

Please close this pull request and remake it from a fork of this feedstock.

Have a great day!

[ccordoba12]

I did suggest that :)

I just saw that you indeed did it, sorry again. But shouldn't the branch be created before merging this PR?

[JarrettSJohnson]

I just saw that you indeed did it, sorry again. But shouldn't the branch be created before merging this PR?

(Dont mind me jumping in here) I can't make the branch since I'm not a maintainer--I just reopened this PR assuming one of you would make the branch before merging this.

[h-vetinari]

But shouldn't the branch be created before merging this PR?

A branch is just a commit that gets a special reference, which can be added at any time (even for past commits, see the docs). I generally recommend creating branches after a relevant PR has been merged. Otherwise it happens with some regularity that someone creates a branch in anticipation of an "imminent" merge, only for the PR to be delayed by unforeseen problems, while other changes continue flowing into main, and then it becomes more of a hassle to keep the history sane.

I can't make the branch since I'm not a maintainer

My offer stands to create the branch; my hope would be though that the (recently updated) docs are good enough that @ccordoba12 would feel empowered to do it himself 🙃

[ccordoba12]

My offer stands to create the branch; my hope would be though that the (recently updated) docs are good enough that @ccordoba12 would feel empowered to do it himself 🙃

I'd prefer for you to do it, if that's ok. The reason I'm always behind in my duties as feedstock maintainer (other than merging update PRs) is that my role as Spyder lead maintainer takes almost all my time.

[ccordoba12]

Approving this just to confirm I agree with this PR.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-webservice.

It appears you are making a pull request from a branch in your feedstock and not a fork. This procedure will generate a separate build for each push to the branch and is thus not allowed. See our documentation for more details.

Please close this pull request and remake it from a fork of this feedstock.

Have a great day!

[h-vetinari]

Sorry, this somehow slipped my radar, I just got reminded of this by something else again. Here's the brandnew qt5 branch: https://github.com/conda-forge/pyqt-feedstock/tree/qt5

So let's merge this. :)

[h-vetinari]

Please don't press the big purple button here to delete the branch yet, but rather check out conda-forge/admin-requests#1907 :)