PR: Fix issues with installers discovered after 6.0.0b2 was released

[mrclary]

Description of Changes

• Patch recipe conda_build_config.yaml on CI in order to replicate the build string hash on conda-forge.
• Use recipe_clobber.yaml and recipe_append.yaml mechanisms to patch meta.yaml instead of find/replace.
• Include label/spyder_dev in the url for Spyder in the conda-lock file, if non-stable distribution
• Fix an issue where the shortcut was not found after macOS update, preventing post-update launching of Spyder.

Issue(s) Resolved

Fixes #22201

[mrclary]

So this PR mostly resolves the build string hash mismatch between our CI built and conda-forge built Spyder package. The osx-arm64 builds still do not match, however. The cause appears to be that conda-forge builds the Spyder package on osx-64, with osx-arm64 as target. Our CI builds on osx-arm64. This results in the following hash inputs for conda-forge:

{'recipe': {'build_platform': 'osx-64',
            'channel_targets': 'conda-forge spyder_dev',
            'python': '3.11.* *_cpython',
            'target_platform': 'osx-arm64'}}

and for our CI:

{'recipe': {'channel_targets': 'conda-forge spyder_dev',
            'python': '3.11.* *_cpython',
            'target_platform': 'osx-arm64'}}

I only see the following possible solutions:

1. Have conda-forge build on osx-arm64 (is this possible?)
2. Have our CI build on osx-64 with osx-arm64 target. I don't like this because it seems to be a regression. Furthermore, since the installer will have to be built on arm64, the installer workflows would have to be refactored.
3. Change our release workflow order to PyPi -> conda-forge -> Github release. This is probably the "correct" solution since this would eliminate patching the feedstock, released packages would be guaranteed to have the same package as traditional conda users, and we would not have to patch the conda-lock file (neither the url nor the md5 checksum). We would still build Spyder on our CI for PRs and pre-release checks, but in these cases the conda-lock file may not be important.

Pinging @spyder-ide/core-developers

[dalthviz]

3. Change our release workflow order to PyPi -> conda-forge -> Github release.

This option makes sense to me 👍

[ccordoba12]

I also agree with @dalthviz. But we'd still be able to test the installers manually before tagging a stable release, as we do now, right @mrclary?

[mrclary]

I also agree with @dalthviz. But we'd still be able to test the installers manually before tagging a stable release, as we do now, right @mrclary?

We'd still be able to manually test. Here is what I'd propose:

1. Manually trigger installer workflow (workflow dispatch pre=true).
2. Manually test installers. Note that the conda-lock file will not be valid since it will not rely on a Spyder conda package from conda-forge.
3. Create release tag (but not a GH release).
4. Publish to PyPi.
5. Publish to conda-forge.
6. Create Github release (using existing tag). This triggers the installer workflow for release.

I would also change our update manager to only check for updates from GH. Then all user types will be alerted to available updates after all assets are guaranteed to be available.

[ccordoba12]

Manually test installers. Note that the conda-lock file will not be valid since it will not rely on a Spyder conda package from conda-forge.

Ok, I think that's a good compromise: we should be able to test the installers before a release but not the update process with them.

[ccordoba12]

Thanks @mrclary!

[mrclary]

I'll submit a follow-up PR:

• Change our installer workflow to use the conda-forge Spyder package on releases only. Nightly, PR, and workflow-dispatch triggers will still build Spyder locally.
• Discontinue patching the conda-lock file.
• Change the update manager plugin to only check GH for releases.