Comments (8)
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.
from setup-python.
- 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
from setup-python.
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
from setup-python.
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!
from setup-python.
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:)
from setup-python.
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?
from setup-python.
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.
from setup-python.
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!😊
from setup-python.
Related Issues (20)
- 3.10.14-9004012336/python-3.10.14-linux-22.04-x64.tar.gz issue HOT 2
- Python 3.5 20.04 tool bundle not installable HOT 3
- Multiple Python versions as a comma-separated list HOT 1
- Non Portable binary, doesn't work with sudo or without LD_LIBRARY_PATH HOT 3
- Custom setuptools version HOT 9
- Cannot load Python modules if they are in a directory named "test" HOT 1
- Python 3.7/8/9/10 on Darwin runners fails: Library not loaded: /usr/local/opt/gettext/lib/libintl.8.dylib HOT 5
- Setups HOT 1
- My pro HOT 1
- Missing support for Python 3.8 on Ubuntu 24.04 runner HOT 1
- Caching doesn't seem to save that much time HOT 5
- Version not found when using new arm-based linux runners (ubuntu 22.04) HOT 3
- Add Python 3.12.4 (released 2 days ago) HOT 5
- [Feature Request] Add Python debug builds with `Py_DEBUG` flag HOT 1
- Python 3.12.4: Extract downloaded archive; gzip: stdin: not in gzip format HOT 22
- is python 3.12.4 download assets broken HOT 6
- Python 3.13 fails to install on windows: Offset to Central Directory cannot be held in an Int64. HOT 4
- Verify checksum of downloaded version archive HOT 1
- Support os-release standard HOT 1
- setup-python CI workflows have been broken for more than 2 months HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from setup-python.