PR: Install wheel in macOS build environment

[mrclary]

Description of Changes

Install wheel in macOS standalone build environment

Issue(s) Resolved

Fixes #20834

Affirmation

By submitting this Pull Request or typing my (user)name below,
I affirm the Developer Certificate of Origin
with respect to all commits and content included in this PR,
and understand I am releasing the same under Spyder's MIT (Expat) license.

I certify the above statement is true and correct: @mrclary

[mrclary]

Installing wheel seemed to have fixed the issue, but I don't understand why. Perhaps @CAM-Gerlach has some insight?

[mrclary]

FYI, @spyder-ide/core-developers, after removing the macOS and Windows standalone installer workflows from the master branch (since the will not be used for 6.x), the workflow_dispatch (manual trigger) no longer works. This is because workflow_dispatch must be present in the workflow in the master branch in order for it to be available for any other branch. This was an oversight of mine when submitting #20368.

We may want to discuss whether we want to retain some dummy workflows in the master branch just for this purpose, at least until development on 5.x is completely terminated.

[ccordoba12]

the workflow_dispatch (manual trigger) no longer works

I think @dalthviz found a way to work around that.

[CAM-Gerlach]

We may want to discuss whether we want to retain some dummy workflows in the master branch just for this purpose, at least until development on 5.x is completely terminated.

You could just remove all the triggers but workflow_dispatch from the workflow in master?

I think @dalthviz found a way to work around that.

Oh what was that?

[mrclary]

the workflow_dispatch (manual trigger) no longer works

I think @dalthviz found a way to work around that.

@dalthviz do tell!

[mrclary]

You could just remove all the triggers but workflow_dispatch from the workflow in master?

installer-macos.yml and installer-win.yml no longer exist on the master branch; that is why the workflow_dispatch trigger does not work even though the workflows exist on 5.x.

https://docs.github.com/en/actions/managing-workflow-runs/manually-running-a-workflow#configuring-a-workflow-to-run-manually

"To trigger the workflow_dispatch event, your workflow must be in the default branch."

[CAM-Gerlach]

installer-macos.yml and installer-win.yml no longer exist on the master branch; that is why the workflow_dispatch trigger does not work even though the workflows exist on 5.x.

Right—what I'm saying is in master, add them back but with only the workflow_dispatch trigger

[mrclary]

Right—what I'm saying is in master, add them back but with only the workflow_dispatch trigger

Oh, sorry for the misunderstanding. Yes, I agree, this is what I meant by a dummy workflow.

[CAM-Gerlach]

It seems we are in violent agreement, then :)

Installing wheel seemed to have fixed the issue, but I don't understand why. Perhaps @CAM-Gerlach has some insight?

Hmm, well the proximate issue appears to be that without wheel in the local env, in the Install Dependencies step pip/Setuptools tries a PEP 660 isolated editable build and install relying on the pyproject.toml metadata, which we don't have (yet):

Obtaining file:///Users/runner/work/spyder/spyder
  Installing build dependencies: started
  Installing build dependencies: finished with status 'done'
  Checking if build backend supports build_editable: started
  Checking if build backend supports build_editable: finished with status 'done'
  Getting requirements to build editable: started
  Getting requirements to build editable: finished with status 'done'
  Preparing editable metadata (pyproject.toml): started
  Preparing editable metadata (pyproject.toml): finished with status 'done'

With wheel it does what appears to be a non-isolated build, gets the metadata from the setup.py (where it is) and may use the legacy editable install method instead (not clear):

Obtaining file:///Users/runner/work/spyder/spyder
  Preparing metadata (setup.py): started
  Preparing metadata (setup.py): finished with status 'done'

I would have to dig a lot deeper (or ask the pip or Setuptools folks I know — the frontend-backend boundary here isn't totally clear from the available output) to figure out why exactly that is. Once I finally get to upgrading the packaging metadata for this repo, I can take a closer look for it seems this solution works for now.

---

Also, just FYI, in the Determine build matrix job, you need to change the line

echo "::set-output name=build_type::{'build_type':$(echo $build_type)}"

to

echo "name=build_type::{'build_type':$(echo $build_type)}" >> $GITHUB_OUTPUT

to avoid the warning (which will become an error in a month and a half:

Warning: The `set-output` command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

per this changelog entry.

[mrclary]

Hmm, well the proximate issue appears to be that without wheel in the local env, in the Install Dependencies step pip/Setuptools tries a PEP 660 isolated editable build and install relying on the pyproject.toml metadata, which we don't have (yet):

I would have to dig a lot deeper (or ask the pip or Setuptools folks I know — the frontend-backend boundary here isn't totally clear from the available output) to figure out why exactly that is. Once I finally get to upgrading the packaging metadata for this repo, I can take a closer look for it seems this solution works for now.

I figured it had something to do with that black magic stuff that I don't understand. I just think it's odd that the behavior would change when none of the inputs have changed...

Also, just FYI, in the Determine build matrix job, you need to change the line

Yes, I've started incorporating that into all my other workflows and just haven't updated it here yet.

[ccordoba12]

Looks good to me, thanks @mrclary!

[mrclary]

@CAM-Gerlach, do you want to review this or are we okay?

[dalthviz]

Just in case, when doing the pre release steps for Spyder 5.4.3 I was able to run the workflows related with the installers by using the GitHub CLI, I did notice that the button to trigger the workflows was unavailable from the GitHub web interface but maybe using the GitHub CLI workarounds that since you can provide a ref from where to run the workflow? 🤔

Anyhow, I described the usage of the GitHub CLI for running the workflows here: https://github.com/spyder-ide/spyder/blob/5.x/RELEASE.md#check-release-candidate

[mrclary]

Okay, I'll just add some dummy workflows back into master in another PR.

[ccordoba12]

are we okay?

I think we're okay. This is a relatively simple change which will fix our CIs in 5.x, so let's merge it.