Make sur that PYENV_TEST_DIR is created if mktemp failed
mock python3 usage by updating create_executable function
fix test by adding the right PATH
update path in plugin test
replace for loop with while read
don't use symlink for stub
* Fix specifying XCode SDK for distutils
* Revert to preferring XCode Zlib
It turns out, everything since 2.7.12 and 3.5.2
can use libs from modern XCode SDK
which is always available unless we're using an alternate compiler
Zlib from XCode is virtually always present now so it only makes sense to use it from elsewhere if it's preferred.
Works around build failure for 2.7 that's incapable of using Zlib from XCode 7+ (see #3301)
* use `xcrun` instead of `xcodebuild` which is absent in CLT
* use an alternative way that's compatible with CPython's setup.py since 3.5.2
---------
Co-authored-by: Ivan Pozdeev <vano@mail.mipt.ru>
Did not implement customizable priority due to unclear use feedback and more compilation in the code, can decide and do that separately
Tcl/Tk from MacPorts support is omitted due to CPython's only being compatible with
Tcl/Tk 9 since 3.12.5 and 3.13.0.
Co-authored-by: Ivan Pozdeev <vano@mail.mipt.ru>
1) Got rid of useless call to `cat`, much better to simply use sed with
file as argument.
2) Got rid of `sort -u`. There is no need to sort the list.
Additionally, the list `pyenv.d/rehash/conda.d/default.list` only has
unique entries, and even if you have duplicate entries, the function
will still work. --> No need for sort nor unique.
3) Further improvement is simple, save a cached
cleaned-list-v1.0 in `conda.d` and simple read from that file instead of
doing `sed`, which must be a more expensive operation than simply
reading from file.
Applies to the conda blacklist in `pyenv.d/rehash/conda.d/default.list`
No practical difference, but it looks misplaced when it sits at the end
of the file.
I was doing some debugging with PYENV_DEBUG=1 and noticed that a lot of
work was being done in conda.bash, even though I had not installed any
conda versions like `mambaforge`.
The solution is pretty simple, put all the code inside an if-block.
This aligns with what @varikin found in his pull request #3037
Additionally, I have refactored the code slightly for readability
(created function `build_conda_exclusion_list`), and added comments
which should make it easier to understand what's going on.
This commit simplifies debugging and should reduce the execution time of
```bash
eval "$(pyenv init -)"
```
slightly.
macos_build / macos_build (3.10) (push) Waiting to run
macos_build / macos_build (3.11) (push) Waiting to run
macos_build / macos_build (3.12) (push) Waiting to run
macos_build / macos_build (3.13) (push) Waiting to run
macos_build / macos_build (3.9) (push) Waiting to run
pyenv_tests / pyenv_tests (macos-13) (push) Waiting to run
pyenv_tests / pyenv_tests (macos-14) (push) Waiting to run
pyenv_tests / pyenv_tests (ubuntu-20.04) (push) Waiting to run
pyenv_tests / pyenv_tests (ubuntu-22.04) (push) Waiting to run
pyenv_tests / pyenv_tests (ubuntu-24.04) (push) Waiting to run
ubuntu_build / ubuntu_build (3.10) (push) Waiting to run
ubuntu_build / ubuntu_build (3.11) (push) Waiting to run
ubuntu_build / ubuntu_build (3.12) (push) Waiting to run
ubuntu_build / ubuntu_build (3.13) (push) Waiting to run
ubuntu_build / ubuntu_build (3.9) (push) Waiting to run
Now that ubuntu-24 is out of beta at Github
Since for ubuntu_build, we only use one OS version
and the changes between versions are not as drastic as with MacOS,
it seems safe to have it upgrade automatically.
* perf: replace a series of if statements with a case block. Add error
handling for case where unknown option is provided.
Same setup as rbenv-init for reading arguments.
* perf, docs: Recommend users to specify the shell for `pyenv init -`
Speeds up the startup by about 40% (in local testing, from ~50ms to ~30ms).
Reflect this in `pyenv init` hint text.
* style: remove unnecessary `root` variable in pyenv-init
* style: remove unnecessary variable declarations at the top of file in pyenv-init.
* perf: replace `cat <<` calls with `echo`
The builtin `echo` is about 100x faster. In tests, saves about 2-3ms.
* docs: document the `pyenv init - <shell>` performance boost in the Advanced Configuration section.
* style: test_helper.bash: avoid unnecessary ".." in produced PATH
* docs: fix a false statement about completions location in the Advanced Configuration section.
macos_build / macos_build (3.10) (push) Waiting to run
macos_build / macos_build (3.11) (push) Waiting to run
macos_build / macos_build (3.12) (push) Waiting to run
macos_build / macos_build (3.13) (push) Waiting to run
macos_build / macos_build (3.9) (push) Waiting to run
pyenv_tests / pyenv_tests (macos-13) (push) Waiting to run
pyenv_tests / pyenv_tests (macos-14) (push) Waiting to run
pyenv_tests / pyenv_tests (ubuntu-20.04) (push) Waiting to run
pyenv_tests / pyenv_tests (ubuntu-22.04) (push) Waiting to run
ubuntu_build / ubuntu_build (3.10) (push) Waiting to run
ubuntu_build / ubuntu_build (3.11) (push) Waiting to run
ubuntu_build / ubuntu_build (3.12) (push) Waiting to run
ubuntu_build / ubuntu_build (3.13) (push) Waiting to run
ubuntu_build / ubuntu_build (3.9) (push) Waiting to run
Requested in https://github.com/pyenv/pyenv/issues/2680
for deployments with a stock `.pyenv-version` that can use any
of a number of Python versions
and for compatibility with `uv`.
* Support `pyenv local --force`
* Support `pyenv-version-file-write --force`
* Support `pyenv version-name --force`
* Ignore missing versions when searching for executables
* Display "commmand not found" even when there are nonexistent versions
* exec.bats: replace `python` and `rspec` with something that doesn't exist globally, either
in Ubuntu Github CI, `python` exists globally
* Reorganize readme, add gif
1. Details in 'Getting Pyenv' and 'Setup for your shell' are collapsed. User can expand relevant
sections depending on their platform and shell.
2. 'How It Works' and 'Advanced Configuration' are moved to the bottom of the README.md
just before 'Contributing' section at the end.
3. Added a GIF in the 'Usage' section to showcase
- Listing python versions available for install.
- Installing a specific python version.
- Listing installed python versions.
- Switching to another python version for a directory.
- Testing by moving terminal into the directory and moving back.
* Update GIF to show prefix resolution
* Collapse upgrade notes
* Cross-mention Linux and MacOS instlalation scenarios
---------
Co-authored-by: Ivan Pozdeev <vano@mail.mipt.ru>
Since 3.13, CPython is provided in 2 flavors: regular and
free-threaded, with the 't' suffix.
An incomplete prefix ending with '[0-9]t'
resolves only among versions that also end with '[0-9]t'
macos_build / macos_build (3.10) (push) Has been cancelled
macos_build / macos_build (3.11) (push) Has been cancelled
macos_build / macos_build (3.12) (push) Has been cancelled
macos_build / macos_build (3.8) (push) Has been cancelled
macos_build / macos_build (3.9) (push) Has been cancelled
pyenv_tests / pyenv_tests (macos-13) (push) Has been cancelled
pyenv_tests / pyenv_tests (macos-14) (push) Has been cancelled
pyenv_tests / pyenv_tests (ubuntu-20.04) (push) Has been cancelled
pyenv_tests / pyenv_tests (ubuntu-22.04) (push) Has been cancelled
ubuntu_build / ubuntu_build (3.10) (push) Has been cancelled
ubuntu_build / ubuntu_build (3.11) (push) Has been cancelled
ubuntu_build / ubuntu_build (3.12) (push) Has been cancelled
ubuntu_build / ubuntu_build (3.8) (push) Has been cancelled
ubuntu_build / ubuntu_build (3.9) (push) Has been cancelled
Fixes use of version specifiers like `python-3.12`, which:
- have an explicit `python-` prefix
- are using a major version alias that has to be resolved
to an exact version.
Also simplified the conditional for the already
working case, since it had two branches that were virtually identical.
The directory /usr/etc is an optional directory and used by
Fedora, RHEL 9, and openSUSE. The purpose of /usr/etc is to store
distribution-provided configuration files that can be overridden
by user-modified files in /etc.
/usr/etc is not in FHS. However, as Torsten stated in his comment
(https://github.com/thkukuk/atomic-updates_and_etc/issues/2#issuecomment-524848666)
"[FHS] is currently nearly as dead as LSB, we can only ignore it
if we don't want to stop and kill all innovation."
This PR corrects a small but important detail in the documentation regarding how the system searches for executable files. The original text incorrectly stated that the operating system performs this search. The corrected text clarifies that it is actually the shell that performs the search.
We always detect missing build scripts for `4.13.0-0` because the
release[^1] doesn't have any mambaforge artifacts. Given that we've
already created the build files, we don't need to check the release
again.
[^1]: https://github.com/conda-forge/miniforge/releases/tag/4.13.0-0
The glob pattern we were using was too permissive and detecting
miniconda build scripts as miniforge build scripts when they shared the
same version. I have rewritten the pattern matching code to ensure we
only look at files starting with `miniforge` and `mambaforge`.
In exceptional cases (custom installation, malfunctions elsewhere), `pyenv-commands --sh` may return nothing.
In non-Fish, this would cause "syntax error near unexpected token `)'" in `pyenv()`.
Bash does not allow to specify a `case` option that would never match.
This works around it by defaulting to `/`. Commands, being filenames, can never match it.
In Fish, nothing needs to be done: it apparently does interpret a `case` without argument as one that never matches.
The code for determining which Python version is bundled with which
version of Anaconda has not been updated in a while. I have added 3.10
and 3.11, both of which were used in bundles this year.
I also updated the URL for the source of this data, the Anaconda release
notes, because it has moved.
XCode Command Line Tools 15.0 was recently released, and it contains a
broken version of ncurses 6.0. Some uses of Python's `curses` module
will segfault when compiled with it. The solution is to switch to using
the version of ncurses from Homebrew, which is currently 6.4. Support
for ncurses 6 was added to Python 3.7 and was backported to 3.6 and 2.7,
so this change should not break any recently supported Python versions.
Tested with Python 3.12, 3.11, and 2.7, and all tests in
the `test.test_curses` module pass without issue.
See https://github.com/python/cpython/issues/109617 and
https://github.com/python/cpython/issues/69906 for more information.
It seems that pyenv cannot install 2.7.18 on Mac M1 (Apple ARM).
openssl 1.0.2 does not have ARM support. M1 support was added in 1.1.1i according to
https://www.openssl.org/news/cl111.txt
All include directories should go into CPPFLAGS.
XCode SDK was being added to CFLAGS instead
which caused old Tcl/Tk in the SDK to override a newer one in Homebrew.
According to the POSIX spec, an unescaped backslash not followed by
an escapable character is undefined behavior,
and it has become an error in GNU grep 3.8 (2022-09-02).
The -s flag assures that nothing can be installed to user site-packages
but doesn't keep ensurepip from looking there for Pip.
If Pip is installed in the user site-packages directory, pip won't be installed
for the newly built python -- and its shim won't be created.
-I makes the build install Pip in any case.
The user site-packages installation will override it --
but we'll have the shim at least.
Guthub have recently preinstalled x64 Homebrew OpenSSL to stock MacOS runners. This has caused FreeBSD OpenSSL detection logic to erroneously trigger when running FreeBSD tests in MacOS because their paths happened to coincide.
Replaced checking a specific path with checking with pkg.
Anaconda and miniconda have changed their version string format again,
so the parsing needs to be done differently. `add_miniconda.py` can now
parse all existing definition files properly.
* Support ksh versions
Korn shell had two major versions: ’88 and ’93. Some systems have
ksh installed under the name `ksh93`. A few systems (maybe only
Solaris now) also have a `ksh88`. A few others use the `pdksh` (’88)
or `mksh` (’93) implementations, originated before ksh was open source.
Limit to currently-used versions
---------
Co-authored-by: Kevin Schoedel <kps@datatravelandexperiments.com>
The manpage contains a reference to a file which does
only exist on Debian (/usr/share/pyenv/pyenv_user_setup.bash).
It is replaced by its content to make it usable for
other distributions.
This takes inspiration from the similar script for miniconda, but it
simplifies in a couple of ways:
1. Use the GitHub Releases API instead of scraping HTML.
2. Don't perform a diff, simply add the latest release.
Lots of intermediate miniconda releases have been skipped in the past,
and it doesn't seem particularly valuable to backfill those.
The auto-resolve feature (#2487) means that
pyenv install miniforge3
installs miniforge3-4.10.3-10 and not the exactly named "miniforge3"
recipe. Renaming "miniforge3" to "miniforge3-latest" solves this
issue allowing users to execute
pyenv install miniforge3-latest
This is similar to the naming of the current "miniconda3-latest" recipe.
In some advanced shell setups, the order of custom-added PATH entries is important.
We disregard it by default, always pushing shims to the front of PATH,
to ensure that Pyenv works even in poorly maintained shell environments
and with minimal hassle for non-export users
(an attempt to do the opposite (#1898) has ended in a disaster).
Some advanced users are however ready and able to carefully maintain their environment
and deal with breakages and inconvenience. This option is for them.
* Document listing available versions in the tutorial (#1677)
* Reflect 3.7.15's extended support
* Document using development head with Homebrew
* Structurize the Upgrading section
* Fix Pyenv-latest documentation
For some reason checksum for `Python-3.11.0.tgz` file introduced in
0726e02e3a is invalid. Update that
checksum to ensure `pyenv install 3.11.0` works well on systems without
tar.xz support.
* CI: Bump OS versions
Github released ubuntu-22.04 and macos-12 from beta
and deprecated ubuntu-18.04 and macos-10.15, due to dropping by 2013.
* CI: clean up installed packages
* Don't bother reading empty version files
* Implement version file read in pure bash
Is faster with usual sized version files, slower with degenerate cases.
We're going to eliminate the need to mandatorily use `pyenv init --path`.
We can't delete it yet for backward compatibility.
Besides, there's one other use case for it: to enable shims but without
shell integration, e.g. for noninteractive shells.
To be a full-fledged replacement for `pyenv init -` however,
it needs to do rehashing.
Now the setup is to add to both rc and profile:
1) set PYENV_ROOT
(can do it unconditionally -- since if you change it,
you need to update all places anyway since any of them can be run first)
2) Add `pyenv` to PATH if not already there
3) eval "$(pyenv init -)"
Not a breaking change, old setup will continue to work.
Trace logs without `-v` are usually useless due to missing the build part.
So this leaves one less thing for users to worry about
when submitting error reports.
Mentioning `-v` in the issue template should stay for some time
since users report on old versions, too.
This reverts commit 90d0d20508.
After further consideration, we've decided to remove this workaround:
* It only has an effect if the user has added `gnubin` from Homebrew Coreutils to PATH which is an unsupported setup
* It was intended to be applied only to a few select 3.8 and 3.9 versions that officially support Apple Silicon and only fail with Homebrew Coreutils in PATH because they have `config.*` from a too old version of Autoconf that doesn't support the Arm64 arch -- but
* CPython devs [didn't actually fix the problem in 3.10, either, only in 3.11](https://github.com/pyenv/pyenv/pull/2157#issuecomment-968055387), so we'd need to apply it to all 3.10 releases, too
* users started pushing this workaround into other unrelated branches because they were using the above unsupported setup. See https://github.com/pyenv/pyenv/pull/2190#pullrequestreview-835221952 for discussion.
In my previous work on getting Python 3.6.15 and 3.7.12 to compile on
Apple M1, I backported logic from newer 3.8.x releases to properly find
libffi and related files on macOS.
This regressed compilation on Linux. The include search path was
incomplete, and `ffi.h` could not be found, resulting in `ctypes` being
disabled.
There was a key difference between the old logic and new logic that led
to this regression:
1. In 3.8 and newer, `detect_ctypes()` in `setup.py` took no arguments,
and was expected to access instance variables for the include search
path.
2. In 3.7 and earlier, `detect_ctypes()` took the path as an argument,
and was expected to make use of it.
The backport made use of the instance variables, overriding the provided
include path. These were not equivalent. The one on the instance was not
complete, lacking the necessary directories to find `ffi.h`. Since this
could not be found, `ctypes` support was disabled.
The fix is to simply not overwrite the variables passed to the function,
and resume using them as before.
Fixes#2207
This change ports pyenv and Python patches to 3.7.12 to enable the
`ctypes `and `decimal` modules to compile.
While Python 3.7.12 itself compiles on arm64/M1, both of these modules
fail to compile, due to missing support for locating system libffi and
due to architecture gate-keeping. These issues have been fixed in newer
releases of Python, and in other pyenv patch bundles.
The following patches are provided:
1. `0001-Port-ctypes-and-system-libffi-patches-for-arm64-macO.patch` -
Fixes system `ffi.h`/`libffi` path determination and usage and
enables calling of variadic functions, fixing ctypes support
(consolidated port of existing pyenv patches for 2.7.18 that iterate
on this logic).
2. `0002-bpo-41100-fix-_decimal-for-arm64-Mac-OS-GH-21228.patch` -
Adds arm64 to the list of allowable architectures for the
`decimal` module (port of Python patch introduced in 3.8.10).
This change ports several established patches to the Python 3.6.15
build, enabling compilation on arm64/Apple M1 architectures:
1. `0001-Detect-arm64-in-configure.patch` -
Updates configure to detect arm64 architectures (port of an existing
pyenv patch for 2.7.18).
2. `0002-bpo-36231-Support-building-on-macOS-without-usr-incl.patch` -
Adds macOS SDK root computation logic for determining include paths
(port of existing Python patches introduced in 2.7.17 and 3.7.4).
3. `0003-Fix-macOS-_tkinter-use-of-Tck-Tk-in-Library-Framewor.patch` -
Fixes Tcl/Tk support on macOS (port of an existing pyenv patch
for 2.7.18).
4. `0004-Port-ctypes-and-system-libffi-patches-for-arm64-macO.patch` -
Fixes system `ffi.h`/`libffi` path determination and usage and
enables calling of variadic functions, fixing ctypes support
(consolidated port of existing pyenv patches for 2.7.18 that iterate
on this logic).
5. `0005-BPO-41100-Support-macOS-11-when-building-GH-21113.patch` -
Updates Darwin version checks to handle macOS 11's major version
bump (port of Python patches introduced in 3.7.0 and 3.9.0).
6. `0006-bpo-41100-fix-_decimal-for-arm64-Mac-OS-GH-21228.patch` -
Adds arm64 to the list of allowable architectures for the
`decimal` module (port of Python patch introduced in 3.8.10).
The issue has been resolved in ed38af6409
but the bounty didn't trigger -- allegedly 'cuz it's not a PR.
Bountysource support replied "we're looking" but never did anything
so I'm going to try to trigger it via a dummy PR.
This is needed to find other Python deps (e.g. libintl) in Homebrew if it has
nonstandard prefix (e.g. in Apple M1)
* Re-allow to search Homebrew for zlib everywhere
Link to the active version like other Homebrew deps --
this won't break when another binary-compatible version is installed.
Use a discovery method that doesn't break when other versions are present alongside.
In GNU `sed`, the `-iEe` argument is equivalent to `--in-place=Ee`, which would create `~/.profileEe` as backup of `~/.profile` if the command executed successfully. However, because the `e` is no longer being processed as an expression argument, `sed` does not correctly join the expressions and exits with `sed: -e expression #2, char 10: unexpected }`.
The intent is to use extended regex, perform the changes in-place, and use a series of expressions, so `-Ei -e` is used instead.
This is essentially the same fix as in pull request #2047, but it
is applied from Python 2.6.6 to 2.6.9, and for `ossaudiodev` as well
as the (deprecated) `linuxaudiodev`.
With the normal `setup.py`, the installation of the `ossaudiodev`
module is skipped under GNU/Linux with newer kernel versions because
Python 3.1 appends the major kernel version to the result of
`build_ext.get_platform` and later `ossaudiodev` is skipped if the
major kernel version is not 2. A similar problem might occur if
installing in FreeBSD.
This problem may even occur if installing Python 3.1 in a Docker image
of an old OS (e.g. prehistoric Debian or CentOS), because the major
kernel version is still the one of the host system.
The solution is to use `str.startswith` and only check that the
platform starts with 'linux' or 'freebsd'.
@@ -17,5 +17,10 @@ Make sure you have checked all steps below.
- [ ] pyenv version:
- [ ] Python version:
- [ ] C Compiler information (e.g. gcc 7.3):
- [ ] Please attach verbose build log as gist
*You can turn on verbose debug logging using by setting `PYENV_DEBUG=1`, e.g. `env PYENV_DEBUG=1 pyenv install -v 3.6.4`
- [ ] Please attach the debug trace of the failing command as a gist:
*Run `env PYENV_DEBUG=1 <faulty command> 2>&1 | tee trace.log` and attach `trace.log`. E.g. if you have a problem with installing Python, run `env PYENV_DEBUG=1 pyenv install -v <version> 2>&1 | tee trace.log` (note the `-v` option to `pyenv install`).
- [ ] If you have a problem with installing Python, please also attach `config.log` from the build directory
* The build directory is reported after the "BUILD FAILED" message and is usually under `/tmp`.
- [ ] If the build succeeds but the problem is still with the build process (e.g. the resulting Python is missing a feature), please attach
* the debug trace from reinstalling the faulty version with `env PYENV_DEBUG=1 pyenv install -f -k -v <version> 2>&1 | tee trace.log`
*`config.log` from the build directory. When using `pyenv install` with `-k` as per above, the build directory will be under `$PYENV_ROOT/sources`.
* [ ] Make sure your problem is not listed in [the common build problems](https://github.com/pyenv/pyenv/wiki/Common-build-problems).
* [ ] Make sure no duplicated issue has already been reported in [the pyenv issues](https://github.com/pyenv/pyenv/issues?q=is%3Aissue). For build errors, a reported issue typically mentions a key error message. This key error message is often not in the 10 last build log lines reported to the console but is rather earlier in the build log -- typically, it's the first error message encountered in the log.
* [ ] Make sure you are reporting a problem in Pyenv and not seeking consultation with Pyenv usage.
* GitHub issues are intended mainly for Pyenv development purposes. If you are seeking help with Pyenv usage, check [Pyenv documentation](https://github.com/pyenv/pyenv?tab=readme-ov-file#simple-python-version-management-pyenv), go to a user community site like [Gitter](https://gitter.im/yyuu/pyenv), [StackOverflow](https://stackoverflow.com/questions/tagged/pyenv), etc, or to [Discussions](https://github.com/orgs/pyenv/discussions).
* [ ] Make sure your problem is not derived from packaging (e.g. [Homebrew](https://brew.sh)).
* Please refer to the package documentation for the installation issues, etc.
* [ ] Make sure your problem is not derived from plugins.
* This repository is maintaining `pyenv` and the default `python-build` plugin only. Please refrain from reporting issues of other plugins here.
### Describe the bug
A clear and concise description of what the bug is.
Do specify what the expected behaviour is if that's not obvious from the bug's nature.
#### Reproduction steps
Listing the commands to run in a new console session and their output is usually sufficient.
Please use a Markdown code block (three backticks on a line by themselves before and after the text) to denote a console output excerpt.
Usually not needed for build errors (since the arguments can already be seen in the debug trace) unless you are using an unusual invocation (e.g. setting environment variables that affect the build).
#### Diagnostic details
- [ ] Platform information (e.g. Ubuntu Linux 24.04):
- [ ] OS architecture (e.g. amd64):
- [ ] pyenv version:
- [ ] Python version:
- [ ] C Compiler information (e.g. gcc 7.3):
- [ ] Please attach the debug trace of the failing command as a [gist](https://gist.github.com/):
* Run `env PYENV_DEBUG=1 <faulty command> 2>&1 | tee trace.log` and attach `trace.log`. E.g. if you have a problem with installing Python, run `env PYENV_DEBUG=1 pyenv install -v <version> 2>&1 | tee trace.log` (note the `-v` option to `pyenv install`).
- [ ] If you have a problem with installing Python, please also attach `config.log` from the build directory
* The build directory is reported after the "BUILD FAILED" message and is usually under `/tmp`.
- [ ] If the build succeeds but the problem is still with the build process (e.g. the resulting Python is missing a feature), please attach
* the debug trace from reinstalling the faulty version with `env PYENV_DEBUG=1 pyenv install -f -k -v <version> 2>&1 | tee trace.log`
*`config.log` from the build directory. When using `pyenv install` with `-k` as per above, the build directory will be under `$PYENV_ROOT/sources`.
- [ ] If the problem happens in another Pyenv invocation, turn on debug logging by setting `PYENV_DEBUG=1`, e.g. `env PYENV_DEBUG=1 pyenv local 3.6.4`, and attach the resulting trace as a gist
- [ ] If the problem happens outside of a Pyenv invocation, get the debug trace like this:
* What your general environment is if it's relevant to the feature request and is not a generic console with a typical Pyenv installation (CI, server with a custom setup, cloud environment, IDE)
* What you are trying to achieve
* What specifically you are doing for that regarding Pyenv
* Where you are stuck
**Describe the solution you'd like**
A clear and concise description of what you want to happen.
**Describe alternatives you've considered**
A clear and concise description of any alternative solutions or features you've considered.
[ ] In particular, did you consider [writing a plugin](https://github.com/pyenv/pyenv/blob/master/README.md#pyenv-plugins)? Note that if your plugin has general applicability, you can publish it in the 3rd-party plugin catalog on the Pyenv Wiki as per the link above.
**Additional context**
Add any other context or screenshots about the feature request here.
* Add CPython 3.12.12, 3.11.14, 3.10.19, 3.9.24 by @nedbat in https://github.com/pyenv/pyenv/pull/3344
## Release v2.6.9
* CI: modified-scripts-build: fix CPython-specific jobs never firing by @tuzi3040 in https://github.com/pyenv/pyenv/pull/3338
* CI: modified-scripts-build: fix output variable for CPython-specific workflows by @native-api in https://github.com/pyenv/pyenv/pull/3340
* Add CPython 3.14.0 by @SnoopJ in https://github.com/pyenv/pyenv/pull/3339
* Add CPython 3.13.8 by @jsirois in https://github.com/pyenv/pyenv/pull/3341
## Release v2.6.8
* Use Zlib from XCode SDK in a way compatible with XCode 16 and CLT by @JarheadStever in https://github.com/pyenv/pyenv/pull/3301
* Add miniforge 25.3.0-1, 25.3.0-2, 25.3.0-3, 25.3.1-0, skip miniforge 25.3.0-0 by @native-api in https://github.com/pyenv/pyenv/pull/3306
* Fix Readline and OpenSSL detection for MacPorts without the corresponding package by @native-api in https://github.com/pyenv/pyenv/pull/3317
* Bump actions/checkout from 4 to 5 in the github-actions group by @dependabot[bot] in https://github.com/pyenv/pyenv/pull/3318
* Fix rehash hook for pipx/pipx.x/pipx.xx by @rockandska in https://github.com/pyenv/pyenv/pull/3320
* Add miniconda 25.7.0-2 by @native-api in https://github.com/pyenv/pyenv/pull/3323
* Support curl from a snap by @native-api in https://github.com/pyenv/pyenv/pull/3329
* CI: Bats test suite in docker by @rockandska in https://github.com/pyenv/pyenv/pull/3324
* Add GraalPy 25.0.0 by @msimacek in https://github.com/pyenv/pyenv/pull/3331
* Upgrade pip detetcion in pip-rehash to accept multiple variations by @rockandska in https://github.com/pyenv/pyenv/pull/3330
* Add CPython 3.14.0rc3 by @nedbat in https://github.com/pyenv/pyenv/pull/3333
* Use TCLTK_* and pkg-config for 3.11+ linking with Homebrew Tcl/Tk; add PYTHON_BUILD_TCLTK_FORMULA envvar by @native-api in https://github.com/pyenv/pyenv/pull/3327
## Release v2.6.7
* Skip Zlib from XCode for XCode 16+ by @native-api in https://github.com/pyenv/pyenv/pull/3298
* Don't fail the build if `xcodebuild` fails by @native-api in https://github.com/pyenv/pyenv/pull/3302
* Add CPython 3.14.0rc2 and 3.13.7 by @nedbat in https://github.com/pyenv/pyenv/pull/3303
## Release v2.6.6
* Add anaconda3-2025.06-0, anaconda3-2025.06-1, miniconda3-25.3.1-1, miniconda3-25.5.1-0, miniconda3-25.5.1-1 by @native-api in https://github.com/pyenv/pyenv/pull/3295
* Add CPython 3.13.6 by @cesarcoatl in https://github.com/pyenv/pyenv/pull/3297
## Release v2.6.5
* Bump OpenSSL to 3.5.1 in the latest releases and branch tips in CPython 3.12 - 3.15 by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/3287
* Add Jython 2.7.4 by @cesarcoatl in https://github.com/pyenv/pyenv/pull/3290
* Add CPython 3.14.0rc1 by @nedbat in https://github.com/pyenv/pyenv/pull/3293
* Add GraalPy 24.2.2 by @msimacek in https://github.com/pyenv/pyenv/pull/3291
## Release v2.6.4
* Backport bpo_36106 to 3.5.10 and 3.6.15 by @native-api in https://github.com/pyenv/pyenv/pull/3280
* (regression) Use Zlib from XCode SDK in MacOS without Homebrew or Macports by @native-api in https://github.com/pyenv/pyenv/pull/3282
* Add PyPy v7.3.20 by @jsirois in https://github.com/pyenv/pyenv/pull/3284
* Add CPython 3.14.0b4 by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/3285
## Release v2.6.3
* README: Re-promote "Python versions with extended support" to a section by @native-api in https://github.com/pyenv/pyenv/pull/3276
* Support linking to MacPorts ports installed from binary archives by @0916dhkim in https://github.com/pyenv/pyenv/pull/3272
* Add CPython 3.14.0b3 by @nedbat in https://github.com/pyenv/pyenv/pull/3278
## Release v2.6.2
* Add CPython 3.13.5 by @nedbat in https://github.com/pyenv/pyenv/pull/3269
## Release v2.6.1
* Add CPython 3.9.23, 3.10.18, 3.11.13, 3.12.11, 3.13.4 by @nedbat in https://github.com/pyenv/pyenv/pull/3266
## Release v2.6.0
* python-build: Support patch paths with spaces/special characters by @native-api in https://github.com/pyenv/pyenv/pull/3251
* Add CODEOWNERS file by @native-api in https://github.com/pyenv/pyenv/pull/3247
* README: make fish PATH add conditional on the directory existing by @BooleanCat in https://github.com/pyenv/pyenv/pull/2786
* Add --bare option to `pyenv version` by @jjwatt in https://github.com/pyenv/pyenv/pull/2783
* README: Add shell setup instructions for nushell by @jordanst3wart in https://github.com/pyenv/pyenv/pull/2916
* Add MacPorts support for python-build by @studnitskiy in https://github.com/pyenv/pyenv/pull/3186
* python-build: fix `has_broken_mac_readline` when Readline is explicitly configured by @fofoni in https://github.com/pyenv/pyenv/pull/3254
* Add CPython 3.14.0b2 by @nedbat in https://github.com/pyenv/pyenv/pull/3259
## Release v2.5.7
* Point 3.14-dev to `3.14` branch by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/3246
## Release v2.5.6
* Add GraalPy 24.2.1 by @msimacek in https://github.com/pyenv/pyenv/pull/3238
* Fix get-pip URLs for 3.7, 3.8 and Pyston by @dmrlawson in https://github.com/pyenv/pyenv/pull/3242
* [CI] Cache `uname` and `sw_vers` output in Python-Build for easier mocking in tests by @native-api in https://github.com/pyenv/pyenv/pull/3244
* Add CPython 3.14.0b1 and 3.15-dev by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/3245
## Release v2.5.5
* Add graalpy 24.2 by @msimacek in https://github.com/pyenv/pyenv/pull/3215
* Switch 3.9+ to OpenSSL 3 by @native-api in https://github.com/pyenv/pyenv/pull/3223
* Add miniforge3-24.11.3-1, miniforge3-24.11.3-2, miniforge3-25.1.1 by @native-api in https://github.com/pyenv/pyenv/pull/3224
* Add CPython 3.9.22, 3.10.17, 3.11.12, 3.12.10, 3.13.3, 3.14.0a7 by @native-api in https://github.com/pyenv/pyenv/pull/3233
## Release v2.5.4
* Add anaconda3-2025.1.1-2 by @binbjz in https://github.com/pyenv/pyenv/pull/3198
* Add PyPy v7.3.19 by @jsirois in https://github.com/pyenv/pyenv/pull/3205
* Add CPython 3.14.0a6 by @nedbat in https://github.com/pyenv/pyenv/pull/3213
## Release v2.5.3
* Add PyPy v7.3.18 by @dand-oss in https://github.com/pyenv/pyenv/pull/3184
* Add Miniconda3 25.1.1-0 by @binbjz in https://github.com/pyenv/pyenv/pull/3190
* Add miniforge3-25.1.1-0, miniforge3-24.11.3-0 by @native-api in https://github.com/pyenv/pyenv/pull/3191
* Add CPython 3.14.0a5 by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/3194
* Add Miniconda3 25.1.1-1 by @binbjz in https://github.com/pyenv/pyenv/pull/3192
* Update hashes for Python 3.14.0a5 tarballs by @jsirois in https://github.com/pyenv/pyenv/pull/3196
* rehash: Do not execute conda-specific code if conda is not installed by @ChristianFredrikJohnsen in https://github.com/pyenv/pyenv/pull/3151
## Release v2.5.2
* Fix OpenSSL version parsing in python-build script by @threadflow in https://github.com/pyenv/pyenv/pull/3181
* Add GraalPy 24.1.2 by @msimacek in https://github.com/pyenv/pyenv/pull/3176
* Add CPython 3.12.9 and 3.13.2 by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/3183
## Release v2.5.1
* CI: use Ubuntu 24.04; use ubuntu-latest for the ubuntu_build check by @native-api in https://github.com/pyenv/pyenv/pull/3144
* Fix: mistake in configuration hints in `pyenv init` and manpage by @ChristianFredrikJohnsen in https://github.com/pyenv/pyenv/pull/3145
* README: Add recommended curl arguments to suggested installer invocation by @JayBazuzi in https://github.com/pyenv/pyenv/pull/3155
* Add miniforge3-24.11.2-0, miniforge3-24.11.2-1 by @native-api in https://github.com/pyenv/pyenv/pull/3163
* Fix "Unsupported options" error building bundled OpenSSL <3.2.0by@native-apiinhttps://github.com/pyenv/pyenv/pull/3164
@@ -16,6 +17,18 @@ The most common subcommands are:
* [`pyenv versions`](#pyenv-versions)
* [`pyenv which`](#pyenv-which)
* [`pyenv whence`](#pyenv-whence)
* [`pyenv exec`](#pyenv-exec)
* [`pyenv root`](#pyenv-root)
* [`pyenv prefix`](#pyenv-prefix)
* [`pyenv latest`](#pyenv-latest)
* [`pyenv hooks`](#pyenv-hooks)
* [`pyenv shims`](#pyenv-shims)
* [`pyenv init`](#pyenv-init)
* [`pyenv completions`](#pyenv-completions)
## `pyenv help`
List all available pyenv commands along with a brief description of what they do. Run `pyenv help <command>` for information on a specific command. For full documentation, see: https://github.com/pyenv/pyenv#readme
## `pyenv commands`
@@ -78,6 +91,10 @@ or, if you prefer 3.3.3 over 2.7.6,
Python 3.3.3
You can use the `-f/--force` flag to force setting versions even if some aren't installed.
This is mainly useful in special cases like provisioning scripts.
## `pyenv global`
Sets the global version of Python to be used in all shells by writing
@@ -216,11 +233,25 @@ Then install the desired versions:
2.6.8
* 2.7.6 (set by /home/yyuu/.pyenv/version)
You can also install the latest version of Python in a specific version line by supplying a prefix instead of a complete name:
$ pyenv install 3.10
See the [`pyenv latest` documentation](#pyenv-latest) for details on prefix resolution.
An older option is to use the `:latest` syntax. For example, to install the latest patch version for Python 3.8 you could do:
pyenv install 3.8:latest
To install the latest major release for Python 3 try:
pyenv install 3:latest
## `pyenv uninstall`
Uninstall a specific Python version.
Uninstall Python versions.
Usage: pyenv uninstall [-f|--force] <version>
Usage: pyenv uninstall [-f|--force] <version> ...
-f Attempt to remove the specified version without prompting
for confirmation. If the version does not exist, do not
@@ -241,8 +272,15 @@ version of Python, or install a package that provides binaries.
Displays the currently active Python version, along with information on
how it was set.
Usage: pyenv version [--bare]
--bare show just the version name. An alias to `pyenv version-name'
$ pyenv version
2.7.6 (set by /home/yyuu/.pyenv/version)
$ pyenv version --bare
2.7.6
## `pyenv versions`
@@ -278,3 +316,97 @@ Lists all Python versions with the given command installed.
2.6.8
2.7.6
3.3.3
## `pyenv exec`
Usage: pyenv exec <command> [arg1 arg2...]
Runs an executable by first preparing PATH so that the selected Python
version's `bin` directory is at the front.
For example, if the currently selected Python version is 3.9.7:
* The usual principles of respecting existing conventions and making sure that your changes
are in line with the overall product design apply when contributing code to Pyenv.
* We are limited to Bash 3.2 features
That's because that's the version shipped with MacOS.
(They didn't upgrade past it and switched to Zsh because later versions
are covered by GPLv3 which has additional restrictions unacceptable for Apple.)
You can still add performance optimizations etc that take advantage of newer Bash features
as long as there is a fallback execution route for Bash 3.
Formatting PRs
==============
We strive to keep commit history one-concern-per-commit to keep it meaningful and easy to follow.
If a pull request (PR) addresses a single concern (the typical case), we usually squash commits
from it together when merging so its commit history doesn't matter.
If however a PR addresses multiple separate concerns, each of them should be presented as a separate commit.
Adding multiple new Python releases of the same flavor is okay with either a single or multiple commits.
Authoring installation scripts
==============================
Adding new Python release support
---------------------------------
The easiest way to add support for a new Python release is to copy the script from the previous one
and adjust it as necessary. In many cases, just changing version numbers, URLs and hashes is enough.
Do pay attention to other "magic numbers" that may be present in a script --
e.g. the set of architectures and OS versions supported by a release -- since those change from time to time, too.
Make sure to also copy any patches for the previous release that still apply to the new one.
Typically, a patch no longer applies if it addresses a problem that's already fixed in the new release.
For prereleases, we only create an entry for the latest prerelease in a specific version line.
When submitting a newer prerelease, replace the older one.
Adding version-specific fixes/patches
-------------------------------------
We accept fixes to issues in specific Python releases that prevent users from using them with Pyenv.
In the default configuration for a Python release, we strive to provide as close to vanilla experience as practical,
to maintain [the principle of the least surprise](https://en.wikipedia.org/wiki/Principle_of_least_astonishment).
As such, any such fixes:
* Must not break or degrade (e.g. disable features) the build in any of the environments that the release officially supports
* Must not introduce incompatibilities with the vanilla release (including binary incompatibilities)
* Should not patch things unnecessarily, to minimize the risk of the aforementioned undesirable side effects.
* E.g. if the fix is for a specific environment, its logic ought to only fire in this specific environment and not touch execution paths for other environments.
* As such, it's advisable to briefly explain in the PR what each added patch does and why it is necessary to fix the declared problem
Generally, version-specific fixes belong in the scripts for the affected releases and/or patches for them -- this guarantees that their effect is limited to only those releases.
<h3>Backporting upstream patches</h3>
Usually, this is the easiest way to backport a fix for a problem that is fixed in a newer release.
* Clone Python, check out the tag for the appropriate release and create a branch
* Apply existing patches if there are any (with either `patch` or `git am`) and commit
* Cherry-pick the upstream commit that fixes the problem in a newer release
* Commit and `git format-patch`
* Commit the generated patch file into Pyenv, test your changes and submit a PR
Deprecation policy
------------------
We do not provide official support for EOL releases and environments or otherwise provide any kind of extended support for old Python releases.
We do however accept fixes from interested parties that would allow running older, including EOL, releases in environments that they do not officially support.
In addition to the above requirements for release-specific fixes,
* Such a fix must not add maintenance burden (e.g. add new logic to `python-build` that has to be kept there indefinitely)
* Unless the added logic is useful for both EOL and non-EOL releases. In this case, it will be considered as being primarily an improvement for non-EOL releases.
* Support is provided on a "best effort" basis: we do not actively maintain these fixes but won't actively break them, either, and will accept any corrections.
Since old releases never change, it's pretty safe to assume that the fixes will continue to work until a later version
of an environment introduces further incompatible changes.
Advanced changes / adding new Python flavor support
An installation script is sourced from `python-build`. All installation scripts are based on the same logic:
1. Select the source to download and other variable parameters as needed.
This includes showing an error if the user's environment (OS, architecture) is not supported by the release.
Binary releases that only officially support specific distro(s) typically show a warning in other distros instead.
2. Run one of the `install_*` shell functions
`install_*` shell functions defined in `python-build` install Python from different kinds of sources -- compressed package (binary or source), upstream installation script, VCS checkout. Pick one that's the most appropriate for your packaging.
Each of them accepts a couple of function-specific arguments which are followed by arguments that constitute the build sequence. Each `<argument>` in the build sequence corresponds to the `install_*_<argument>` function in `python-build`. Check what's available and add any functions with logic specific to your flavor if needed.
We strive to keep out of `python-build` parts of build logic that are release-specific and/or tend to change abruptly between releases -- e.g. sets of supported architectures and other software's versions. This results in logic duplication between installation scripts -- but since old releases never change once released, this doesn't really add to the maintenance burden. As a rule of thumb, `python-build` can host parts of logic that are expected to stay the same for an indefinite amount of time -- for an entire Python flavor or release line.
@@ -106,7 +108,7 @@ Set or show the shell\-specific Python version
List existing pyenv shims
.TP
.Buninstall
Uninstall a specific Python version
Uninstall Python versions
.TP
.Bversion
Show the current Python version(s) and its origin
@@ -232,6 +234,7 @@ Skip this section unless you must know what every line in your shell profile is
\fBSets up your shims path\.\fR This is the only requirement for pyenv to function properly\. You can do this by hand by prepending \fB$(pyenv root)/shims\fR to your \fB$PATH\fR\.
.IP"2."4
\fBRehashes shims\.\fR From time to time you'll need to rebuild your shim files\. Doing this on init makes sure everything is up to date\. You can always run \fBpyenv rehash\fR manually\.
You can disable this functionality by adding \fB--no-rehash\fR to the end of your \fBpyenv init\fR command line.
.IP"3."4
\fBInstalls the sh dispatcher\.\fR This bit is also optional, but allows pyenv and plugins to change variables in your current shell, making commands like \fBpyenv shell\fR possible\. The sh dispatcher doesn't do anything crazy like override \fBcd\fR or hack your shell prompt, but if for some reason you need \fBpyenv\fR to be a real script rather than a shell function, you can safely skip it\.
@@ -24,7 +24,7 @@ Installing python-build as a standalone program will give you access to the
`python-build` command for precise control over Python version installation. If you
have pyenv installed, you will also be able to use the `pyenv install` command.
git clone git://github.com/pyenv/pyenv.git
git clone https://github.com/pyenv/pyenv.git
cd pyenv/plugins/python-build
./install.sh
@@ -96,7 +96,64 @@ versions of Python that are not yet supported by python-build.
See the [python-build built-in definitions](https://github.com/pyenv/pyenv/tree/master/plugins/python-build/share/python-build) as a starting point for
Without the user customizing the build with environment variables (see below),
`python-build` builds Python with mostly default Configure options
to maintain the principle of the least surprise.
The exceptions -- non-default options that are set by default -- are listed below:
| Option/Behavior | Rationale |
|-----------------|-----------|
| `--enable-shared` is on by default. Pass `--disable-shared` to Configure options to override | The official CPython Docker image uses it. It's required to embed CPython. |
| argument to `--enable-universalsdk` is ignored and set to `/` |
| `--with-universal-archs` defaults to `universal2` on ARM64 architecture | the only dual-architecture Macs in use today are Apple Silicon which can only build that one |
| argument to `--enable-framework` is ignored and set to a specific value | CPython's build logic requires a very specific argument to avoid installing the `Applications` part globally |
| argument to `--enable-unicode` in non-MacOS is overridden to `ucs4` for 2.x-3.3 |
| `MACOSX_DEPLOYMENT_TARGET` defaults to the running MacOS version |
#### Integration with 3rd-party package ecosystems
##### Homebrew
Homebrew is used to find dependency packages if `brew` is found on `PATH`:
* In MacOS, or
* If the running Pyenv itself is installed with Homebrew
Set `PYTHON_BUILD_USE_HOMEBREW` or `PYTHON_BUILD_SKIP_HOMEBREW` to override this default.
When Homebrew is used, its `include` and `lib` paths are added to compiler search path (the latter is also set as `rpath`),
and also Python dependencies that are typically keg-only are searched for in the Homebrew installation and added individually.
**NOTE:** Homebrew is not used in Linux by default because it's rolling-release which causes a problem.
Upgrading a Python dependency in Homebrew to a new major version (that `brew` does without warning)
would break all Pyenv-managed installations that depend on it.
You can use a [community plugin `fix-version`](https://github.com/pyenv/pyenv/wiki/Plugins#community-plugins)
to fix installations in such a case.
##### MacPorts
MacPorts Homebrew is used to find dependency packages if `port` is found on `PATH` in MacOS.
Set `PYTHON_BUILD_USE_MACPORTS` or `PYTHON_BUILD_SKIP_MACPORTS` to override this default.
###### Interaction with Homebrew
If both Homebrew and MacPorts are installed and allowed to be used, Homebrew takes preference.
There first ecosystem where any of the required dependency packages is found is used.
##### Portage
In FreeBSD, if `pkg` is on PATH, Ports are searched for some dependencies that Configure is known to not search for via `pkg-config`.
(Later versions of CPython search for more packages via `pkg-config` so this may eventually become redundant.)
### Special environment variables
@@ -113,21 +170,27 @@ You can set certain environment variables to control the build process.
checksum of the file to the mirror URL.
*`PYTHON_BUILD_SKIP_MIRROR`, if set, forces python-build to download packages from
their original source URLs instead of using a mirror.
*`PYTHON_BUILD_HTTP_CLIENT`, explicitly specify the HTTP client type to use. `aria2`, `curl` and `wget` are the supported values and by default, are searched in that order.
*`PYTHON_BUILD_CURL_OPTS`, `PYTHON_BUILD_WGET_OPTS`, `PYTHON_BUILD_ARIA2_OPTS` pass additional parameters to the corresponding HTTP client.
*`PYTHON_BUILD_SKIP_HOMEBREW`, if set, will not search for libraries installed by Homebrew when it would normally will.
*`PYTHON_BUILD_USE_HOMEBREW`, if set, will search for libraries installed by Homebrew when it would normally not.
*`PYTHON_BUILD_HOMEBREW_OPENSSL_FORMULA`, override the Homebrew OpenSSL formula to use.
*`PYTHON_BUILD_TCLTK_FORMULA`, override the Homebrew Tcl/Tk formula to use.
*`PYTHON_BUILD_SKIP_MACPORTS`, if set, will not search for libraries installed by MacPorts when it would normally will.
*`PYTHON_BUILD_USE_MACPORTS`, if set, will search for libraries installed by MacPorts when it would normally not.
*`PYTHON_BUILD_ROOT` overrides the default location from where build definitions
in `share/python-build/` are looked up.
*`PYTHON_BUILD_DEFINITIONS` can be a list of colon-separated paths that get
additionally searched when looking up build definitions.
*`CC` sets the path to the C compiler.
*`PYTHON_CFLAGS` lets you pass additional options to the default `CFLAGS`. Use
this to override, for instance, the `-O3` option.
*`CONFIGURE_OPTS` lets you pass additional options to `./configure`.
*`MAKE` lets you override the command to use for `make`. Useful for specifying
GNU make (`gmake`) on some systems.
*`MAKE_OPTS` (or `MAKEOPTS`) lets you pass additional options to `make`.
*`MAKE_INSTALL_OPTS` lets you pass additional options to `make install`.
*`PYTHON_CONFIGURE_OPTS` and `PYTHON_MAKE_OPTS` and `PYTHON_MAKE_INSTALL_OPTS` allow
you to specify configure and make options for building CPython. These variables
will be passed to Python only, not any dependent packages (e.g. libyaml).
*`<PACKAGE>_CFLAGS`, `<PACKAGE>_CPPFLAGS`, `<PACKAGE>_LDFLAGS` let you pass additional options to `CFLAGS`/`CPPFLAGS`/`LDFLAGS` specifically for building `<package>` (Python itself or a dependency library) from source as part of the build script. `<PACKAGE>` should be a capitalized name of the package without version (technically, capitalized first argument to `install_package` without version). E.g. for CPython, it's "`PYTHON`", for Readline, "`READLINE`", for PyPy (only applies when building it from source), "`PYPY`". Check the source of the build script you're using if unsure.
you to specify configure and make options for building `<package>` (same as above). "Make install target" would replace "`install`" in the `make install` invocation.
install_package "Python-2.5" "https://www.python.org/ftp/python/2.5/Python-2.5.tgz#d7bbf42e36003c6065cd19f3e67d283521858515ee923220f654131cebe1d8f2" standard verify_py25
install_package "Python-2.5.1" "https://www.python.org/ftp/python/2.5.1/Python-2.5.1.tgz#1f5caee846049ca30d996f9403eefdb996295c4af664867e35dcc5eb36e4e7e8" standard verify_py25
install_package "Python-2.5.2" "https://www.python.org/ftp/python/2.5.2/Python-2.5.2.tgz#834afe8a88adaf623b05ac5dd6700dd5bb5d0d5553fc74ad529359a3496e4ae3" standard verify_py25
install_package "Python-2.5.3" "https://www.python.org/ftp/python/2.5.3/Python-2.5.3.tgz#c3fee607d20a77dfb72ea2e627eb4d95d25c735603435abde62c57015a0445bd" standard verify_py25
install_package "Python-2.5.4" "https://www.python.org/ftp/python/2.5.4/Python-2.5.4.tgz#3d3b205611ee503a38a9433d5645a571668420bb219242c7f51af85f05664da6" standard verify_py25
install_package "Python-2.5.5" "https://www.python.org/ftp/python/2.5.5/Python-2.5.5.tgz#03be1019c4fe93daeb53ba9e4294bf22a8ed4cb854cbd57e24e16f6bf63e2392" standard verify_py25
install_package "Python-2.5.6" "https://www.python.org/ftp/python/2.5.6/Python-2.5.6.tgz#c2e4377597241b1065677d23327c04d0f41945d370c61a491cc88be367234c5d" standard verify_py25
install_package "Python-3.0.1" "https://www.python.org/ftp/python/3.0.1/Python-3.0.1.tgz#7d5f2feae9035f1d3d9e6bb7f092dbf374d6bb4b25abd0d2d11f13bba1cb04de" standard verify_py30
install_package "Python-3.1" "https://www.python.org/ftp/python/3.1/Python-3.1.tgz#99a034cf574ea3c26412b0a0728126d7fd6ea9593d099d807a25d216ed031e6a" standard verify_py31
install_package "Python-3.1.1" "https://www.python.org/ftp/python/3.1.1/Python-3.1.1.tgz#5d85d7bff11c4db44920af99f64f4227c816f897f6bfa9dd8a2611165ca5f0a1" standard verify_py31
install_package "Python-3.1.2" "https://www.python.org/ftp/python/3.1.2/Python-3.1.2.tgz#dffbc0561a161a4a576c6059e6990a9859a0be16ba9b5736eabe4abbb2700d1c" standard verify_py31
install_package "Python-3.1.3" "https://www.python.org/ftp/python/3.1.3/Python-3.1.3.tgz#6311823aeda8be6a7a2b67caaeff48abce6626c9940ba7ed81f9c978666a36bd" standard verify_py31
install_package "Python-3.1.4" "https://www.python.org/ftp/python/3.1.4/Python-3.1.4.tgz#fadc05ea6d05360cff189944a85ecd2180bbc308784d168b350450e70bbdd846" standard verify_py31
install_package "Python-3.1.5" "https://www.python.org/ftp/python/3.1.5/Python-3.1.5.tgz#d12dae6d06f52ef6bf1271db4d5b4d14b5dd39813e324314e72b648ef1bc0103" standard verify_py31
install_package "Python-3.10.14" "https://www.python.org/ftp/python/3.10.14/Python-3.10.14.tar.xz#9c50481faa8c2832329ba0fc8868d0a606a680fc4f60ec48d26ce8e076751fda" standard verify_py310 copy_python_gdb ensurepip
else
install_package "Python-3.10.14" "https://www.python.org/ftp/python/3.10.14/Python-3.10.14.tgz#cefea32d3be89c02436711c95a45c7f8e880105514b78680c14fe76f5709a0f6" standard verify_py310 copy_python_gdb ensurepip
fi
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.