PR: Update conda-lock for change in release workflow

[mrclary]

Description of Changes

We agreed to change the release workflow to PyPi -> conda-forge -> Github in order to produce sound conda-lock files on release for updating our conda-based applications. This results in the following changes to the installer CI workflow and update manager.

• The Spyder conda package will only be built on CI for PRs and workflow-dispatch triggers, not releases
• The conda-lock file will not be patched. For non-release events, this produces an accurate conda-lock file which cannot be used outside CI. For release events, this produces the accurate and portable conda-lock file.
• The update manager only looks at Github for releases.

This is a follow-up PR to #22204

[ccordoba12]

The update manager only looks at Github for releases.

I don't understand the need for this change because:

• PyPI and Conda-forge users can get notifications about new updates more quickly than the ones using our installers, and that's fine.
• Anaconda takes a lot of time (these days it could take between six months to a year) to update to a new version. So, we must not report a new version to them without checking if one is available in its channels (which is what we already have in place).

[mrclary]

I don't understand the need for this change because:

• PyPI and Conda-forge users can get notifications about new updates more quickly than the ones using our installers, and that's fine.

That's not fine since in these circumstances we prompt the user with the opportunity to install the update using our installers. If they accept and those installers are not yet available, then there will be an error.

• Anaconda takes a lot of time (these days it could take between six months to a year) to update to a new version. So, we must not report a new version to them without checking if one is available in its channels (which is what we already have in place).

This is a good point and reveals an existing issue. Currently, in this circumstance, the main channel will be checked for updates, which you point out could be as much as a year behind. This means that users will not even be given the option to use our installer either.

By checking on GH, anaconda users will at least be given a timely opportunity to update using our installer. However, we may need to inform the user that if they do not opt for our installer a new version is not yet available on the main channel.

[ccordoba12]

That's not fine since in these circumstances we prompt the user with the opportunity to install the update using our installers. If they accept and those installers are not yet available, then there will be an error.

Ok, I understand your logic now and you're right about this point.

This is a good point and reveals an existing issue. Currently, in this circumstance, the main channel will be checked for updates, which you point out could be as much as a year behind. This means that users will not even be given the option to use our installer either.

It's unfortunate that we have to do that for Anaconda users, but I don't see other choice (see below).

By checking on GH, anaconda users will at least be given a timely opportunity to update using our installer. However, we may need to inform the user that if they do not opt for our installer a new version is not yet available on the main channel.

The problem is that, with these changes, we'd be informing users that a new version is available regardless of being part of Anaconda. And, although I understand your point of letting users know about a more recent version not present there, as a user I'd be frustrated by trying to install it through Anaconda just to see that it's not really part of it.

So, now I think we should revert the code you removed but only for Anaconda.

[mrclary]

as a user I'd be frustrated by trying to install it through Anaconda just to see that it's not really part of it.

I don't think I understand your point here. As a user, if I'm informed that there is a new version of Spyder available if I use the installer, but there is not a new version available on the main Anaconda channel, then at least I have a choice. Otherwise I don't even know that Spyder is actually more than a year ahead of what I'm using.

If Anaconda installed Spyder users are a year behind, then I think this category of users should be the primary target for nudging to use our installer and not kept ignorant of it.

Perhaps I don't understand completely what you think the user would be frustrated with.

[ccordoba12]

If Anaconda installed Spyder users are a year behind, then I think this category of users should be the primary target for nudging to use our installer and not kept ignorant of it.

I think there are several UX issues with that approach:

• Users can be using Spyder through Anaconda in restricted environments (e.g. schools or companies) that don't allow them to update it on their own.
• In that case, we'd be annoying them for months with a message they can do nothing about.
• But even if that's not the case, I think we need to respect users' choice and not try to force them to use our installers if they decided to go with Anaconda. However, given the amount of downloads we have for our installers, most people find on their own that Anaconda is not the best choice because it's outdated and unstable.

[mrclary]

I think there are several UX issues with that approach:

• Users can be using Spyder through Anaconda in restricted environments (e.g. schools or companies) that don't allow them to update it on their own.
• In that case, we'd be annoying them for months with a message they can do nothing about.

This is only true if "Check for updates on startup" is selected. In the institutional setting that you describe, this should be deselected anyway. Otherwise users will still be as annoyed when Anaconda updates Spyder and users cannot do anything about it. This does not seem to be an issue directly related to our installers or whether GH is used to check for updates.

• But even if that's not the case, I think we need to respect users' choice and not try to force them to use our installers if they decided to go with Anaconda.

I'm not suggesting that we force users to do anything. We inform users (both PyPi and conda users) that a preferred installer is available; the choice is theirs. Under the current situation, Anaconda users would not even be informed of the alternative until much much later.

[mrclary]

@ccordoba12, I restored using the defaults channel for checking for updates when Spyder is installed from that channel.

[ccordoba12]

I restored using the defaults channel for checking for updates when Spyder is installed from that channel.

Thanks @mrclary! We can keep talking about how to inform Anaconda users about updates, but that's a bit ortogonal to the changes you did here.

[ccordoba12]

Thanks @mrclary!