Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent Python version between steps with macos-latest #487

Closed
2 of 5 tasks
jtpio opened this issue Aug 24, 2022 · 2 comments
Closed
2 of 5 tasks

Inconsistent Python version between steps with macos-latest #487

jtpio opened this issue Aug 24, 2022 · 2 comments
Assignees
Labels
bug Something isn't working

Comments

@jtpio
Copy link

jtpio commented Aug 24, 2022

Description:

A couple of days ago some CI checks that run on macos-latest with older versions of Python (3.7, 3.8, 3.9) started failing.

Action version:

actions/setup-python@v4

Platform:

  • Ubuntu
  • macOS
  • Windows

Runner type:

  • Hosted
  • Self-hosted

Tools version:

- name: Install Python
  uses: actions/setup-python@v4
  with:
    python-version: '3.7'
    architecture: 'x64'

Repro steps:

Here is a public example: https://github.com/jupyter/notebook/runs/7973591481

There is also this issue with screenshots comparing macos to linux: jupyterlab/jupyterlab#12991

Expected behavior:

pip should correspond to the Python setup with actions/setup-python (in the example above), when invoked with python -m pip or python3 -m pip.

Actual behavior:

In https://github.com/jupyter/notebook/runs/7973591481 we notice a Python version mismatch:

image


Thanks for your help!

@dmitry-shibanov
Copy link
Contributor

Hello @jtpio. Thank you for your report. I think the issue comes through the specifying the default shell. It prepends extra paths that is why it resolves system python firstly. Could you please get rid of bash -l for python/pip steps ?

@jtpio
Copy link
Author

jtpio commented Aug 24, 2022

Oh nice, many thanks @dmitry-shibanov for the hint 👍

We still need bash on windows to be able to use wildcards in file names. But it seems switching from bash -l {0} to bash -e {0} does the trick.

Linking to this PR where this was investigated, in case other folks experience something similar: jupyter/notebook#6523

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants