Wrong python version installed

[adrian-valente]

Description: In a github action, a call to setup-python@v3 requiring python-version 3.11 actually installs 3.12, causing crashes downstream when conda is called.

Action version: v3

Platform:

• [ ] Ubuntu

Runner type:

• [ ] Hosted

Tools version: 3.11

Repro steps:
Here is the workflow file:

name: Python Package using Conda

on: [push]

jobs:
  build-linux:
    runs-on: ubuntu-latest
    strategy:
      max-parallel: 5

    steps:
    - uses: actions/checkout@v3
    - name: Set up Python 3.11
      uses: actions/setup-python@v3
      with:
        python-version: 3.11
        channels: conda-forge,defaults
        channel-priority: true
    - name: Add conda to system path
      run: |
        # $CONDA is an environment variable pointing to the root of the miniconda directory
        echo $CONDA/bin >> $GITHUB_PATH
    - name: Install dependencies
      run: |
        python --version
        conda install -y python=3.11
        python --version
        $CONDA/bin/conda env update --file environment.yml --name base
    - name: Lint with flake8
      run: |
        # conda install flake8
        # stop the build if there are Python syntax errors or undefined names
        # flake8 . --count --select=E9,F63,F7,F82 --show-source --statistics
        # exit-zero treats all errors as warnings. The GitHub editor is 127 chars wide
        # flake8 . --count --exit-zero --max-complexity=10 --max-line-length=127 --statistics
    - name: Test with pytest
      run: |
        # conda install pytest
        pytest

Expected behavior: The first call to python --version should return a 3.11 release, and hence the conda reinstall of python have no effect.

Actual behavior: However we see on the first call that python 3.12 was installed, despite the requirement in the call to setup-python. Without the conda reinstall of python 3.11, this causes the subsequent conda install to crash with the error: ImportError: cannot import name 'install' from 'conda.cli' (/usr/share/miniconda/lib/python3.12/site-packages/conda/cli/__init__.py). This issue suddenly surfaced less than a month ago, without other modifications to the workflow. It was mentioned on the conda repo in this issue.

[HarithaVattikuti]

Hello @adrian-valente Thank you for creating this issue. We will investigate it and get back to you as soon as we have some feedback.

[MrLucifer-pro]

        - name: Setup Node.js environment

uses: actions/[email protected] with: # Set always-auth in npmrc. always-auth: # optional, default is false # Version Spec of the version to use. Examples: 12.x, 10.15.1, >=10.15.0. node-version: # optional # File containing the version Spec of the version to use. Examples: package.json, .nvmrc, .node-version, .tool-versions. node-version-file: # optional # Target architecture for Node to use. Examples: x86, x64. Will use system architecture by default. architecture: # optional # Set this option if you want the action to check for the latest available version that satisfies the version spec. check-latest: # optional # Optional registry to set up for auth. Will set the registry in a project level .npmrc and .yarnrc file, and set up auth to read in from env.NODE_AUTH_TOKEN. registry-url: # optional # Optional scope for authenticating against scoped registries. Will fall back to the repository owner when using the GitHub Packages registry (https://npm.pkg.github.com/). scope: # optional # Used to pull node distributions from node-versions. Since there's a default, this is typically not supplied by the user. When running this action on github.com, the default value is sufficient. When running on GHES, you can pass a personal access token for github.com if you are experiencing rate limiting. token: # optional, default is ${{ github.server_url == 'https://github.com' && github.token || '' }} # Used to specify a package manager for caching in the default directory. Supported values: npm, yarn, pnpm. cache: # optional # Used to specify the path to a dependency file: package-lock.json, yarn.lock, etc. Supports wildcards or a list of file names for caching multiple dependencies. cache-dependency-path: # optional

[ChristopherRabotin]

Hi @HarithaVattikuti , is there any update on this issue? I'm encountering an issue where I'm specifying an exact version of Python (3.11) but the action also installs 3.12 and 3.13. The subsequent step finds the Python 3.13 executable, and fails to proceed. This issue happens even when I specify a Python range of python-version: '>=3.11 <3.13'.

Build log: https://github.com/nyx-space/hifitime/actions/runs/8476347591/job/23225747105?pr=286

Thanks

Edit:

Here is another build log where the "Remove bad python" section shows that many versions of Python are installed but none are the ones I've asked for: https://github.com/nyx-space/hifitime/actions/runs/8476477745/job/23226053241?pr=286

Run ls -l `which python`; ls -l /usr/bin/python*
lrwxrwxrwx 1 runner runneradmin 10 Mar 24 22:16 /opt/hostedtoolcache/Python/3.11.8/x64/bin/python -> python3.11
lrwxrwxrwx 1 root root       7 Oct 11  2021 /usr/bin/python -> python3
lrwxrwxrwx 1 root root      10 Aug 18  2022 /usr/bin/python3 -> python3.10
lrwxrwxrwx 1 root root      17 Aug 18  2022 /usr/bin/python3-config -> python3.10-config
-rwxr-xr-x 1 root root 5904904 Nov 20 15:14 /usr/bin/python3.10
lrwxrwxrwx 1 root root      34 Nov 20 15:14 /usr/bin/python3.10-config -> x86_64-linux-gnu-python3.10-config

And later:

 Finished release [optimized] target(s) in 11.91s
📦 Built wheel for CPython 3.12 to dist/hifitime-4.0.0.dev0-cp312-cp312-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
   Compiling pyo3-build-config v0.21.0
   Compiling pyo3-macros-backend v0.21.0
   Compiling pyo3-ffi v0.21.0
   Compiling pyo3 v0.21.0
error: failed to run custom build command for `pyo3-ffi v0.21.0`

Caused by:
  process didn't exit successfully: `/home/runner/work/hifitime/hifitime/target/release/build/pyo3-ffi-73ca5b40c431cf69/build-script-build` (exit status: 1)
  --- stdout
  cargo:rerun-if-env-changed=PYO3_PRINT_CONFIG
  cargo:rerun-if-env-changed=PYO3_USE_ABI3_FORWARD_COMPATIBILITY

  --- stderr
  error: the configured Python interpreter version (3.13) is newer than PyO3's maximum supported version (3.12)
  = help: please check if an updated version of PyO3 is available. Current version: 0.21.0

[priya-kinthali]

Hello @adrian-valente 👋, Thank you for your detailed description! The setup-python action seems to be correctly setting up the specified Python version. The discrepancy observed might be attributed to how conda handles Python versions within its environments. A potential workaround could be to create a new environment. This approach permits conda to manage the dependencies within the confines of that specific environment, which results in a more isolated and manageable context for dependency resolution. As for the crash error, it appears to be linked to an issue with conda itself, as you've noted in the description. Hope this clarifies!

[priya-kinthali]

Hello @adrian-valente 👋, Just a gentle ping to see if there are any updates on your end regarding this issue. Your response would be greatly appreciated. Thank you in advance:)


[adrian-valente]

Hello, in my latest workflow run from Tuesday, the problem persisted exactly as stated here. As mentioned it is not critical because one can easily appending conda install -y python=3.11 to their workflow, but I thought at github actions you might want to look for a more permanent answer, which doesn't seem to exist so far?

[adrian-valente]

Maybe I should give more details though, lest you stay stuck: The setup-python action apparently gives a correct result:

Run actions/setup-python@v5
  with:
    python-version: 3.11
    check-latest: false
    token: ***
    update-environment: true
    allow-prereleases: false
Installed versions
  Successfully set up CPython (3.11.8)

However, the next steps of the workflow involve adding conda to the path:

- name: Add conda to system path
  run: |
    # $CONDA is an environment variable pointing to the root of the miniconda directory
    echo $CONDA/bin >> $GITHUB_PATH
- name: Conda info
  run: conda info
- name: Conda list
  run: conda list
- name: Install dependencies
  run: |
    python --version
    conda install -y python=3.11
    python --version

Which immediately causes the python version to jump to 3.12. Keep in mind this is the worflow file as proposed directly by github, so one would expect it to work right away. I am not familiar enough with actions internals to understand how it is executed, but thought you might want to know about the issue.

[priya-kinthali]

Hello @adrian-valente 👋, Thank you for the detailed description! As per our investigation, it appears that the behaviour you're observing is expected based on the current design of the actions/runner-images repository. Specifically, the command used in actions/runner-images downloads the latest version of Miniconda. This, in turn, installs the latest version of Python on the runner, regardless of the python version specified in the setup-python action. Hope this clarifies :)
 We are closing this ticket for now as this is expected behaviour in actions/runner-images. Please feel free to reach us out in case of any other concerns. Your patience and understanding are truly appreciated!😊