Create spyder-base package that does not depend on pyqt

[mrclary]

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.

Fixes #175
Fixes #178

This PR's workflows will fail until the changes in spyder-ide/spyder#23141 are propagated to PyPi.

spyder-ide/spyder#23141 can be merged anytime, since it should only impact installer builds for PRs. This PR should be merged some time after spyder-ide/spyder#23141 is merged, but immediately following upload of the PyPi package prior to a release or release candidate. Once this PR is merged, the remaining release steps can proceed.

Summary

This PR intends to create two packages from one feedstock.

• spyder-base: contains the spyder source code and specifies all of spyder's dependencies except any direct or indirect dependence on pyqt.
• spyder: only specifies spyder's direct and indirect dependencies on pyqt.

The intention is to provide a way for users to use pyside6 rather than pyqt, e.g.

conda install spyder-base pyside6

Installing spyder in the standard fashion will still yield a pyqt-based install.

conda install spyder

Notes

spyder-base was chosen as the "parent" package and spyder as the "subpackage" because the post-link scripts will only be included with the parent package and not the subpackage. Spyder's shortcut (via menuinst) is customized conditioned on the install environment, not target platform, and therefore can only use the post-link mechanism to achieve this. spyder-base must run the post-link scripts at install time, not spyder, in order to provide the shortcut in the case of using pyside6 rather than pyqt. If the Spyder shortcut did not require the post-link mechanism, then we could make spyder the parent package and spyder-base the subpackage.

python {{ python_min }} # [unix] was removed and other selectors were merged in the test environment(s) because it appears that they are not needed. The python spec is not needed for the tests to pass on macOS or Linux and cannot be present on Windows, else the tests fail (the test environment cannot be solved). Removing python and merging selectors in the spyder noarch package also helps ensure the build hash is the same across all platforms.

Concerns

I do not know which application Anaconda Navigator will provide: spyder-base, spyder, or both. The app section is not allowed in an item of the outputs section, i.e. the spyder package, so we cannot explicitly use it for the subpackage and remove it from the parent package. I suspect that Anaconda Navigator will recognize both packages as applications because the app header appears in the rendered meta.yaml for both packages, and this could be confusing. It may also be possible that Anaconda Navigator will only recognize the parent package as an application (i.e. spyder-base), which would be the worst outcome since this would not run without explicitly installing the remaining dependencies.

[mrclary]

@conda-forge-admin, please rerender

[conda-forge-admin]

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

I wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found some lint.

Here's what I've got...

For recipe/meta.yaml:

• ❌ The top level meta keys are in an unexpected order. Expecting ['package', 'source', 'build', 'requirements', 'test', 'app', 'outputs', 'about', 'extra'].
• ❌ noarch packages can't have selectors. If the selectors are necessary, please remove noarch: python.

[mrclary]

@conda-forge-admin, please rerender.

[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.

[conda-forge-admin]

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

I tried to rerender for you, but it looks like there was nothing to do.

_{This message was generated by GitHub actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/11900049814.}

[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). Your recipe may not receive automatic updates and/or may not be compatible with conda-forge's infrastructure. Please check the logs for more information and ensure your recipe can be parsed.

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

[mrclary]

@conda-forge-admin , please rerender

[mrclary]

@conda-forge-admin please rerender

[conda-forge-admin]

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

I wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found some lint.

Here's what I've got...

For recipe/meta.yaml:

• ❌ The outputs section contained an unexpected subsection name. app is not a valid subsection name.

For recipe/meta.yaml:

• ℹ️ The recipe is not parsable by parser conda-souschef (grayskull). Your recipe may not receive automatic updates and/or may not be compatible with conda-forge's infrastructure. Please check the logs for more information and ensure your recipe can be parsed.

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

[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). Your recipe may not receive automatic updates and/or may not be compatible with conda-forge's infrastructure. Please check the logs for more information and ensure your recipe can be parsed.

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

[mrclary]

I tried to move the app section to outputs/app because I think we should want spyder to be the Anaconda Navigator app, not spyder-base, but it appears that the outputs/app section is not allowed.

For recipe/meta.yaml:

• ❌ The outputs section contained an unexpected subsection name. app is not a valid subsection name.

[mrclary]

For recipe/meta.yaml:

• ℹ️ The recipe is not parsable by parser conda-souschef (grayskull). Your recipe may not receive automatic updates and/or may not be compatible with conda-forge's infrastructure. Please check the logs for more information and ensure your recipe can be parsed.

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

@hmaarrfk, do you have a recommendation to satisfy conda-souschef? It appears to be complaining about the duplicate key string, but these have selectors...

[hmaarrfk]

Can you help me understand the goal of keeping this updated?

Is the intention of the Spyder Team to make Spyder Compatible with qt backends other than PyQt5?

[dalthviz]

Thanks @mrclary and @hmaarrfk for your work here!

[hmaarrfk]

again, my question remains, does spyder actually support any backend other than Qt5 for now?

[mrclary]

again, my question remains, does spyder actually support any backend other than Qt5 for now?

I'm going to say no. But I'll let @ccordoba12 give a more precise answer.

[hmaarrfk]

so why merge this?

[dalthviz]

again, my question remains, does spyder actually support any backend other than Qt5 for now?

I would say no right now but in the future we most probably will move to Qt6 (after all Qt5 EOL is coming soon). For more info about future Qt6 support the discussion is being done over spyder-ide/spyder#20201

[hmaarrfk]

i guess i've been following the general Spyder+Qt testing history. Generally it has been "approach with caution and ultimately not supported outside of PyQt5".

I'm wondering whether or not it was the right time to merge this so quickly.

Ultimately, ccordoba12 has been very active in maintaining this feedstock. He has also asked quite nicely that other downstream packagers don't rush a release of spyder + qt6.

Maybe there was a conversation that happened outside of this PR that I missed, but I would have liked to hear his thoughts on this before we merged... I was mostly helping get the syntax correct for the recipe...

[ccordoba12]

again, my question remains, does spyder actually support any backend other than Qt5 for now?

Yes, it works with PyQt6 too. There is an minor, annoying bug with it, but we plan to fix that in our next version (6.0.5).

I know PyQt6 is not available in Conda-forge yet, but we plan to change that soon (perhaps you could give us a hand with it?)

so why merge this?

Several reasons:

• The work for this on the Spyder and Conda-forge sides was already done by @mrclary, so we didn't want to leave it in branches that could easily get outdated with new releases and dependency changes.
• Our standalone installers are based on our Conda-forge package, so we wanted to check that they work as expected with these changes.
• This is the first step to start supporting Qt6, so we wanted to merge it asap.

[hmaarrfk]

Ok as long as you were ok with it!

[ccordoba12]

Yep, I am. Sorry if I didn't chime in sooner, but we talked about this work at length with @mrclary and @dalthviz in our internal meetings.