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'.
The original 2.3 portable version was compiled on Ubuntu 20.04 and didn't work with older glibc.
This has been fixed and the older file has been deleted so hopefully this change is acceptable.
...rather than login mode.
I couldn't get rid of the warning that `pyenv init -` no longer sets path until I did this. It looks like setting only on the login shell wasn't enough to hide the warning in other shells I opened. This fits with [how rbenv does the same thing](https://github.com/rbenv/rbenv/blob/master/libexec/rbenv-init#L74).
I'm way out of my depth here, so someone who knows about shell types should definitely review this.
Debian/Ubuntu's stock `~/.bashrc` prepends `~/.local/bin` to `PATH` towards its end if it exists.
Executables for per-user modules for system Python are installed into `~/.local/bin` --
so need to prepend `shims` to `PATH` later that that.
Co-authored-by: Ivan Pozdeev <vano@mail.mipt.ru>
Ensuring that all dirs in LDFLAGS exist is only needed for Ruby due to its `configure` requirements.
If some LDFLAGS entries point to a nonexisting path to which the user doesn't have permission. this causes a build failure.
* Update install instructions for Bash and Zsh
* Synchronize README.md with `pyenv init`
* Add a ~/.bash_profile note
* Concatenate shims activation into installation for brevity
(Pyenv can't be used meaningfully without shims anyway)
Otherwise, we'd need to duplicate all the ~/.profile shenanigans in both sections
* Update based on feedback
* Proofread
In certain cases, a user wants to know the cached filename to add the file themselves,
see https://github.com/pyenv/pyenv/issues/1743 .
Since we report both a filename and a URL anyway, there's no reason to report a wrong one.
This behavior is only triggered when the version is provided as an empty string,
is undocumented and breaks if multiple local versions are specified
(rightly so since it's unclear which of them to install).
E.g. for a GUI session, ~/.profile is executed by the GUI login "shell" at its startup
so one needs to fully log out and log back in.
Before that, the change would only be seen by shells explicitly started as login shells.
To support building for Apple ARM64 which was introduced in MacOS 11
OpenSSL added support for Apple ARM in 1.1.1
(61168b5b8d).
Python added support for MacOS 11 in 3.7.8+, 3.8.4+, 3.9.0+
(https://github.com/python/cpython/pull/21113 and backports).
Sometimes it is convenient to be able to temporarily disable something
in a version-file. Because these files often aren't necessarily tracked
in a SCM, especially when working with virtualenvs, the SCM diffs won't
help with showing removed lines which are currently the only way to
disable something.
* Update PyPy download links. Remove releases that are no longer available.
PyPy has moved from bitbucket.org to foss.heptapod.net.
Downloads have moved to https://downloads.python.org/pypy/; some of the archives are no longer available.
Portable PyPy has moved from bitbucket.org to Github. Old archives have been moved to a 3rd-party "Bitbucket Archive" site.
* Update Stackless download links. Remove releases that are no longer available.
Stackless has moved from Bitbucket to Github. Old downloads have been renamed(?); stackless.com no longer works via HTTPS.
* Delete releases that have become invalid since the last check
* fix changed checksums
"hyperfine pyenv-versions" before with my bash 4.4:
Time (mean ± σ): 81.7 ms ± 2.2 ms [User: 67.8 ms, System: 15.7 ms]
Range (min … max): 78.3 ms … 87.2 ms 34 runs
After:
Time (mean ± σ): 70.6 ms ± 2.4 ms [User: 55.6 ms, System: 16.9 ms]
Range (min … max): 67.9 ms … 78.9 ms 41 runs
"hyperfine pyenv-rehash" before on my bash 4.4:
Time (mean ± σ): 172.8 ms ± 8.2 ms [User: 185.0 ms, System: 24.8 ms]
Range (min … max): 164.2 ms … 198.4 ms 15 runs
After:
Time (mean ± σ): 113.8 ms ± 2.8 ms [User: 127.1 ms, System: 26.1 ms]
Range (min … max): 108.0 ms … 117.6 ms 25 runs
OS X arm64 will be installed with Python 3.9 only. Other versions bundled with python 3.8. Miniforge does not have as wide a choice of python versions as miniconda.
The Python version is specific only to the base environment.
... which is caused by `realpath.dylib` containing illegal UTF-8 byte sequence, and `LC_CTYPE` won't take effect if `LC_ALL` happens to be set to something other than `C`.
This commit fixes issue pyenv/pyenv#1454.
Ref: https://stackoverflow.com/a/23584470
PyPy has now only one development tip, `default`,
others are version-line-specific maintenance branches.
The py3k branch has been closed in 2016.
As such, a separate pypy3-dev entry no longer makes sense.
Remove extra whitespace in quoted package_url#checksum string.
Prevent the following error:
unexpected checksum length: 65 (e2562a8d235adc19be5451c170837f53ef916aec4cd5cd17d9e0ab1f1b875d3f )
expected 0 (no checksum), 32 (MD5), or 64 (SHA2-256)
The test "prefix for system in /" is duplicated in test/prefix.bats.
Both tests are completely identical. This commit removes the
duplication.
It appears that the culprit is this merge from rbenv/master, from 2016:
cf1beda362
With the current development version of bats, this leads to the
following error when running `make test`:
Error:
Duplicate test name(s) in file
"/home/travis/build/pyenv/pyenv/test/prefix.bats":
test_prefix_for_system_in_-2f
Note that the development version is what pyenv's Makefile uses. With
the latest release of bats, the duplication only leads to a warning:
bats warning:
duplicate test name(s) in /src/test/prefix.bats:
test_prefix_for_system_in_-2f
* Pin bats to the latest release (1.2.0)
This fixes the following error when running `make test` with bats
installed from its master branch:
/src/bats/libexec/bats-core/bats-exec-file:
line 192:
bats-exec-test:
command not found
The Makefile currently runs bats from its master branch. This can lead
to errors when bats is broken between releases, as is currently the case
with bats at the following commit:
bats-core/bats-core@b615ed8f75
Instead, use the latest release of bats, which is 1.2.0 (2020-04-25).
* Pin bats to latest release on Travis CI
This PR fixes (currently harmless) warning on macOS when homebrew is *not* installed.
- [ ] Test case (required?)
For example:
```sh
wadkar$ pyenv install 3.8.2
/Users/wadkar/.pyenv/plugins/python-build/bin/python-build: line 1541: brew: command not found
/Users/wadkar/.pyenv/plugins/python-build/bin/python-build: line 1541: brew: command not found
Installing openssl-1.1.0j...
Installed openssl-1.1.0j to /Users/wadkar/.pyenv/versions/3.8.2
Installing readline-8.0...
Installed readline-8.0 to /Users/wadkar/.pyenv/versions/3.8.2
Installing Python-3.8.2...
python-build: use zlib from xcode sdk
Installed Python-3.8.2 to /Users/wadkar/.pyenv/versions/3.8.2
```
## before
```Usage: pyenv <command> [<args>]
Some useful pyenv commands are:
commands List all available pyenv commands
local Set or show the local application-specific Python version
global Set or show the global Python version
shell Set or show the shell-specific Python version
install Install a Python version using python-build
uninstall Uninstall a specific Python version
rehash Rehash pyenv shims (run this after installing executables)
version Show the current Python version and its origin
versions List all Python versions available to pyenv
which Display the full path to an executable
whence List all Python versions that contain the given executable
See `pyenv help <command>' for information on a specific command.
For full documentation, see: https://github.com/pyenv/pyenv#readme
```
## after
```
Usage: pyenv <command> [<args>]
Some useful pyenv commands are:
commands List all available pyenv commands
local Set or show the local application-specific Python version
--version Display the version of pyenv
commands List all available pyenv commands
exec Run an executable with the selected Python version
global Set or show the global Python version
help Display help for a command
hooks List hook scripts for a given pyenv command
init Configure the shell environment for pyenv
install Install a Python version using python-build
local Set or show the local application-specific Python version
prefix Display prefix for a Python version
rehash Rehash pyenv shims (run this after installing executables)
root Display the root directory where versions and shims are kept
shell Set or show the shell-specific Python version
shims List existing pyenv shims
uninstall Uninstall a specific Python version
update update pyenv and plugins
version Show the current Python version and its origin
version-file Detect the file that sets the current pyenv version
version-name Show the current Python version
version-origin Explain how the current Python version is set
versions List all Python versions available to pyenv
whence List all Python versions that contain the given executable
which Display the full path to an executable
See `pyenv help <command>' for information on a specific command.
For full documentation, see: https://github.com/pyenv/pyenv#readme
```
This was imported semi-automatically in 0965577, but `ruby -S` is
different from `python -S`.
`ruby -S`: look for the script using PATH environment variable
`python -S`: don't imply 'import site' on initialization
infocmp is a system utility that returns information about the user's terminal. When it is shimmed it can cause problems for various programs that use it to determine terminal settings. In particular, the library used by the Scala shell reads it and problems can occur where various control keys don't work (e.g. backspace does not work).
previously, it was not possibly to compile a python with homebrew
openssl 1.1 because the code always queried "openssl" and ignored
"openssl@1.1".
now, if 1.1 is installed, it is used to compile python and only
if it is not, 1.0 is checked and used.
All scripts in libexec/ (excluding pyenv) are called through pyenv,
therefore the shebang lines are not necessary. On some systems this
provides a measurable increase in performance of the shell prompt.
Related to pyenv/pyenv-virtualenv#259
The script in `Tools/gdb/libpython.py` has helper functions for
debugging Python processes under gdb. When installed to `{exe}-gdb.py`
it will automatically be loaded by gdb assuming it is in the safe path.
gdb resolves all symlinks, so having the single script is sufficient
regardless of how Python is invoked.
Since it is usually only included as part of a dbg/dev package, this
file is intentionally excluded from install by the CPython build
scripts. Like the packaging with EPEL/Debian, we opt to manually copy
it after the build/install.
To ensure this file gets picked up it is enough for users to put this in
their `~/.gdbinit`:
```
add-auto-load-safe-path ~/.pyenv
```
Fixes#1190.
Command `rbenv version-name > .ruby-version` will create an empty `.ruby-version` file
before running `rbenv-version-file`. This causes `rbenv-version-file` to return empty
string which in turn causes `rbenv-version-name` to return `system`.
Ensure size of `.ruby-version` is non-zero as a workaround.
The current checksums for tar.xz and .tgz files are reversed. This
causes python-build to fail with a checksum mismatch error.
Reversing the checksums to allow the build to succeed.
Add `clear` to the Anaconda's default blacklist in order to prevent
pyenv from creating the shim script for it.
The `clear` command executable began included from Anaconda 5.0.0
onwards, and this executable now conceals that of the user's base system
- this hinders the user from running the `clear` command with the
`command not found` error output if a user installs and selects one or
more Python version(s) other than Anaconda 5.x.x.
Adding this one-liner to the blacklist allows the user to use the
`clear` command even when Anaconda 5.x.x is not selected by pyenv.
pyenv install crashes on Solaris with an empty log file. Adding support for the proper Solaris getconf call in num_cpu_cores fixed it. Tested and working under OmniOS CE r151024.
Shell integration is not enabled by default. This means that, from all the
commands from `rbenv commands`, only "shell" won't work right away.
Replace "no such command" with a more descriptive message that points to
`rbenv init` instead.
Add `tput` to the Anaconda's default blacklist in order to prevent pyenv
from creating the shim script for it.
Anaconda 5.0.0 contains some executables which are part of the base
system. Many of these executables did not exist in the last major
version of Anaconda (`4.4.0`), and the existence of pyenv's shim
scripts for these executables in `5.0.0` can cause to conceal those
executables in the user's base system; for the details, please see the
discussion with @yyuu at #992.
This commit resolves a coloured output error when running a terminal
command which uses `tput`. This error occurs when multiple Python
versions are installed alongside `anaconda2-5.0.0` or `anaconda3-5.0.0`
and neither of those two Anaconda versions is selected by pyenv.
* Move Homebrew to the top, common case for new devs
* Note that `brew install rbenv` includes ruby-build by default
* Be clear that `rbenv init` instructions are needed for shell setup
* Be explicit about starting a new shell to pick up PATH/init changes
* Use rbenv-doctor to conclusively demonstrate correct setup
* Separate upgrade instructions for Homebrew vs Git installs
Related: https://github.com/rbenv/ruby-build/pull/1106
I work on a team that has followed the Homebrew installations. More than once we've missed the `rbenv init` instruction and it has caused headaches down the road. This formatting makes it harder to miss.
The setenv function in fish shell has changed dramatically in
75600b6b53
It now conforms to the csh version, which takes at most two arguments.
In this init script, the form
setenv PATH prepend_something $PATH
had been used, which had too many arguments.
Since setenv isn't a native command in fish, a suitable replacement is
to use the "set -gx" command, which can consume multiple arguments.
The package names in the python-build files for anaconda2-4.2.0 and
anaconda2-4.3.0 both had 'Anaconda2-4.2.1-MacOSX-x86_64' erroneously
listed as the package name. Anaconda2-4.2.1 is not a version of Anaconda
in existence. The URL arguments were correct, just not the package name
arguments.
* Updated docs to reflect homebrew change.
The instructions previously mentioned in this file were removed from the Homebrew caveats since
they weren't specific to homebrew. See discussion in [this homebrew issue](https://github.com/Homebrew/homebrew-core/pull/11209)
* Added link to specific section of readme
This allows subcommand style plugins to properly autocomplete.
Existing commands are not affected.
Example, say you have support for `rbenv foo bar --flag`, then
this allows the last `--flag` argument to be properly completed.
This allows subcommand style plugins to properly autocomplete.
Existing commands are not affected.
Example, say you have support for `pyenv foo bar --flag`, then
this allows the last `--flag` argument to be properly completed.
Keeping rbenv-controlled variables to RBENV_* "namespace" helps with
discoverability (and tools like rbenv-env) but also consistency and a
very minor degree of safety/isolation from env impact.
This ensures that OLD_RBENV_VERSION is never exported. This makes the
implementation a little bit more complex, since more logic needs to be
pushed down into eval'd code.
The literal tilde in a PATH entry (e.g. `~/.rbenv/shims`) doesn't seem
to be supported by system `which` utility, but *does* seem to be
supported by `command -v` (used in `rbenv-which`) and `type -p`.
Therefore, we must strip away `~/.rbenv/shims` from PATH when looking up
executables for system Ruby, lest we risk infinite loop. We do so by
substituting any occurence of `~` in PATH with the value of `HOME`.
The plugin pyenv-default-packages uses `$(pyenv root)/default-packages`
as configuration file. Since this plugin is listed as approved, I
assume it makes sense to have the file permanently ignored by Git.
The performance issue must be caused by too many I/O requests to
`conda.txt` from fgrep. This inline expansion should work to reduce # of
read to the `conda.txt`.
original performance:
```
% git rev-parse HEAD
4f76be6a12
% time bash -c 'pyenv rehash'
bash -c 'pyenv rehash' 0.05s user 0.02s system 76% cpu 0.089 total
```
previous commit: ==> 4x slower than original
```
% git rev-parse HEAD
4469d51ef7
% time bash -c 'pyenv rehash'
bash -c 'pyenv rehash' 0.06s user 0.03s system 25% cpu 0.358 total
```
with this workaround: ==> almost same as original
```
% git rev-parse HEAD
3ffe91bdbc69220eaecf6e2088229cc27366c3f3
% time bash -c 'pyenv rehash'
bash -c 'pyenv rehash' 0.05s user 0.00s system 68% cpu 0.082 total
```
Actually I'm not 100% sure what was going on, but it seems CPython build
script may create `bin` as directory instead of symlink even if
`--enable-framework` was specified.
`aria2c` doesn't support writing content to stdout. As a workaround,
this patch will use temporary file then write content on stdout once
finished downloading.
Per [the fish documentation for "source"](file:///usr/local/Cellar/fish/2.2.0/share/doc/fish/commands.html#source) - ". (a single period) is an alias for the source command. The use of . is deprecated in favour of source, and . will be removed in a future version of fish."
`rbenv shell -` allows you to switch to the previously activated ruby
version. Similar to `cd -` or `git checkout -`.
This tries to implement `rbenv shell -` as proposed in #854. However,
adding support seemed to break the "shell change version" test. I'm not
very good at Bash programming, can someone tell me what is wrong with
what I'm doing? I'd like to add a bit more functionality to this, but
I'm really just cargo cult programming Bash.
Thank you!
fix tests
2016-01-12 15:32:59 -08:00
1019 changed files with 29831 additions and 2639 deletions
Too many issues will kill our team's development velocity, drastically.
Make sure you have checked all steps below.
### Prerequisite
* [ ] 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). You should look for closed issues, too.
* [ ] Make sure you are not asking us to help solving your specific issue.
* GitHub issues is opened mainly for development purposes. If you want to ask someone to help solving your problem, go to some community site like [Gitter](https://gitter.im/yyuu/pyenv), [StackOverflow](https://stackoverflow.com/questions/tagged/pyenv), etc.
* [ ] 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.
### Description
- [ ] Platform information (e.g. Ubuntu Linux 16.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:
* 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`.
* [ ] Please consider implementing the feature as a hook script or plugin as a first step.
* pyenv has some powerful support for plugins and hook scripts. Please refer to [Authoring plugins](https://github.com/pyenv/pyenv/wiki/Authoring-plugins) for details and try to implement it as a plugin if possible.
* [ ] Please consider contributing the patch upstream to [rbenv](https://github.com/rbenv/rbenv), since we have borrowed most of the code from that project.
* We occasionally import the changes from rbenv. In general, you can expect changes made in rbenv will be imported to pyenv too, eventually.
* Generally speaking, we prefer not to make changes in the core in order to keep compatibility with rbenv.
* [ ] My PR addresses the following pyenv issue (if any)
* Add CPython 3.12.3 by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/2941
* Add CPython 3.13.0a6 by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/2942
* Add PyPy v7.3.16 by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/2948
* Add CPython 3.14-dev, update 3.13-dev by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/2960
* Add CPython 3.13.0b1 by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/2959
## Release v2.4.0
* Add CPython 3.13.0a4 by @saaketp in https://github.com/pyenv/pyenv/pull/2903
* Handle the case where `pyenv-commands --sh` returns nothing by @aphedges in https://github.com/pyenv/pyenv/pull/2908
* Document default build configuration customizations by @native-api in https://github.com/pyenv/pyenv/pull/2911
* Use Homebrew in Linux if Pyenv is installled with Homebrew by @native-api in https://github.com/pyenv/pyenv/pull/2906
* Add miniforge and mambaforge 22.11.1-3, 22.11.1-4, 23.1.0-0 to 23.11.0-0 by @aphedges in https://github.com/pyenv/pyenv/pull/2909
* Add miniconda3-24.1.2 by @binbjz in https://github.com/pyenv/pyenv/pull/2915
* Minor grammar fix in libffi backport patch in 2.5.x by @cuinix in https://github.com/pyenv/pyenv/pull/2922
* Add CPython 3.13.0a5 by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/2924
* Add CPython 3.8.19 and 3.9.19 by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/2929
* Add GraalPy 24.0.0 by @msimacek in https://github.com/pyenv/pyenv/pull/2928
* Add CPython 3.10.14 by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/2930
* Add Jython 2.7.3 by @cesarcoatl in https://github.com/pyenv/pyenv/pull/2936
* Add CPython 3.11.9 by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/2938
* Add anaconda 2024.02 by @native-api in https://github.com/pyenv/pyenv/pull/2939
## Release v2.3.36
* Add a Dependabot config to auto-update GitHub action versions by @kurtmckee in https://github.com/pyenv/pyenv/pull/2863
* Bump the github-actions group with 1 update by @dependabot in https://github.com/pyenv/pyenv/pull/2864
* Add installation prefix to `python-config --ldflags` output by @mhaeuser in https://github.com/pyenv/pyenv/pull/2865
* Add support for miniconda3 23.11.0-1, 23.11.0-2 with py3.11, py3.10, py3.9, py3.8 by @binbjz in https://github.com/pyenv/pyenv/pull/2870
* Add micropython 1.20.0 and 1.21.0 by @cpzt in https://github.com/pyenv/pyenv/pull/2869
* Make "Automatic installer" command in the README a copy-able code block by @ryan-williams in https://github.com/pyenv/pyenv/pull/2874
* Add PyPy 7.3.14 by @dand-oss in https://github.com/pyenv/pyenv/pull/2876
* Add graalpy-23.1.2 by @msimacek in https://github.com/pyenv/pyenv/pull/2884
* Add CPython 3.13.0a3 by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/2885
* Add PyPy v7.3.15 by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/2886
* Update pypy3.9-7.3.13 checksums by @ecerulm in https://github.com/pyenv/pyenv/pull/2887
* Add CPython 3.12.2 by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/2899
* Add CPython 3.11.8 by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/2898
## Release v2.3.35
* Add CPython 3.12.1 by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/2861
## Release v2.3.34
* Fix graalpy-community to use a separate package name by @native-api in https://github.com/pyenv/pyenv/pull/2855
* Move 3.11.5+ to OpenSSL 3 by default by @native-api in https://github.com/pyenv/pyenv/pull/2858
* Add CPython 3.11.7 by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/2860
## Release v2.3.33
* Add miniforge3-23.3.1-1 by @goerz in https://github.com/pyenv/pyenv/pull/2839
* Add support for miniconda3-3.11-23.10.0-1 by @binbjz in https://github.com/pyenv/pyenv/pull/2843
* Add support for miniconda3 23.10.0-1 with py3.10、py3.9、py3.8 by @binbjz in https://github.com/pyenv/pyenv/pull/2844
* Add CPython 3.13.0a2 by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/2849
* python-build: Document PYTHON_BUILD_HOMEBREW_OPENSSL_FORMULA and PYTHON_BUILD_HTTP_CLIENT by @native-api in https://github.com/pyenv/pyenv/pull/2853
## Release v2.3.32
* Describe --no-rehash option in the manpage by @fsc-eriker in https://github.com/pyenv/pyenv/pull/2832
* Make adding $PYENV_ROOT/bin to PATH independent of other software by @native-api in https://github.com/pyenv/pyenv/pull/2837
* Make `pyenv init` output insertable to startup files by @native-api in https://github.com/pyenv/pyenv/pull/2838
## Release v2.3.31
* Add new anaconda and miniconda definitions by @aphedges in https://github.com/pyenv/pyenv/pull/2824
## Release v2.3.30
* Fix intermittent "broken pipe" in tests by @native-api in https://github.com/pyenv/pyenv/pull/2817
* Add CPython 3.13.0a1 by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/2818
* Add PyPy 7.3.13 by @dand-oss in https://github.com/pyenv/pyenv/pull/2807
* Fix linking against Homebrew's Tcl/Tk 8.6.13 in MacOS by @startergo in https://github.com/pyenv/pyenv/pull/2820
## Release v2.3.29
* Add CPython 3.11.6 by @thecesrom in https://github.com/pyenv/pyenv/pull/2806
* Add GraalPy 23.1.0 definition using the faster Oracle GraalVM distribution by @eregon in https://github.com/pyenv/pyenv/pull/2812
* Install ncurses from Homebrew, if available by @aphedges in https://github.com/pyenv/pyenv/pull/2813
## Release v2.3.28
* Prioritize 'zlib from xcode sdk' flag correctly by @native-api in https://github.com/pyenv/pyenv/pull/2791
* Prefer OpenSSL 3 in Homebrew in 3.13-dev by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/2793
* Add CPython 3.12.0rc3 by @saaketp in https://github.com/pyenv/pyenv/pull/2795
* Add graalpy-23.1.0 and split between graalpy and graalpy-community by @msimacek in https://github.com/pyenv/pyenv/pull/2796
* Update the OpenSSL dependency for Python 2.7.18 by @lpapp-foundry in https://github.com/pyenv/pyenv/pull/2797
* Add CPython 3.12.0 by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/2804
## Release v2.3.27
* Prefer OpenSSL 3 in Homebrew since 3.12 by @native-api in https://github.com/pyenv/pyenv/pull/2781
* Fix get-pip urls for older pypy versions by @TimPansino in https://github.com/pyenv/pyenv/pull/2788
* Update openssl url for 3.12.0rc2 by @zsol in https://github.com/pyenv/pyenv/pull/2789
## Release v2.3.26
* Prevent `grep` warning in `conda.bash` by @aphedges in https://github.com/pyenv/pyenv/pull/2768
* fix a typo in README.md by @xzmeng in https://github.com/pyenv/pyenv/pull/2769
* use -I with ensurepip by @xaocon in https://github.com/pyenv/pyenv/pull/2764
* Add CPython 3.12.0rc2 by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/2778
## Release v2.3.25
* Add CPython 3.8.18, 3.9.18, 3.10.13, 3.11.5 by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/2763
## Release v2.3.24
* README update: Added UNIX reference near Automatic installer by @VictorieeMan in https://github.com/pyenv/pyenv/pull/2744
* Fix FreeBSD tests in MacOS CI by @native-api in https://github.com/pyenv/pyenv/pull/2748
* Add CPython 3.12.0rc1 by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/2752
* [Add an updated Anaconda and Miniconda installers](https://github.com/pyenv/pyenv/commit/db871427c7a232e18ee7a6dc0182989a646ccca9)
## Release v2.3.23
* Add CPython 3.12.0b4 by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/2741
* Add new anaconda and miniconda definitions by @aphedges in https://github.com/pyenv/pyenv/pull/2742
## Release v2.3.22
* Add CPython 3.12.0b3 by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/2730
* Add Cinder 3.10 and Cinder configure patches by @filips123 in https://github.com/pyenv/pyenv/pull/2739
## Release v2.3.21
* Add graalpy-23.0.0 by @msimacek in https://github.com/pyenv/pyenv/pull/2724
* Add PyPy 7.3.12 by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/2726
* Fix occasional 'libexec/pyenv-latest: line 39: printf: write error: Broken pipe' by @native-api in https://github.com/pyenv/pyenv/pull/2729
## Release v2.3.20
* Backport bpo-42351 to 3.5.10 by @native-api in https://github.com/pyenv/pyenv/pull/2717
* Add missing patches for Python 3.7/3.8/3.9 by @tomkins in https://github.com/pyenv/pyenv/pull/2718
## Release v2.3.19
* Add CPython 3.7.17, 3.8.17 and 3.9.17 by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/2711
* Add CPython 3.11.4 by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/2715
* Add CPython 3.10.12 by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/2714
* Add CPython 3.12.0b2 by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/2713
## Release 2.3.18
* Fix not showing symlink contents for unselected versions in `pyenv versions` by @native-api in https://github.com/pyenv/pyenv/pull/2675
* Correct link in has_tar_xz_support else branch of 3.10.11 and 3.11.3 by @mirekdlugosz in https://github.com/pyenv/pyenv/pull/2677
* Fix #2682: Correct pyenv_user_setup.bash file by @tomschr in https://github.com/pyenv/pyenv/pull/2687
* fix: updating heredoc delimiter to be random and unique by @aviadhahami in https://github.com/pyenv/pyenv/pull/2691
* Support ksh alternative names by @kpschoedel in https://github.com/pyenv/pyenv/pull/2697
* Add CPython 3.12.0b1 by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/2701
* Update 3.12-dev and add 3.13-dev by @t0b3 in https://github.com/pyenv/pyenv/pull/2703
## Release 2.3.17
* Try locate `readlink` first in pyenv-hooks, fix #2654 by @Harry-Chen in https://github.com/pyenv/pyenv/pull/2655
* Add CPython 3.12.0a7 by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/2668
* Add CPython 3.11.3 by @mirekdlugosz in https://github.com/pyenv/pyenv/pull/2671
* Add CPython 3.10.11 by @mirekdlugosz in https://github.com/pyenv/pyenv/pull/2670
## Release 2.3.16
* Add Miniforge3-22.11.1-4 by @jlec in https://github.com/pyenv/pyenv/pull/2642
* Add Anaconda3-2023.03 by @anton-petrov in https://github.com/pyenv/pyenv/pull/2648
## Release 2.3.15
* Add miniconda 23.1.0-1 by @aphedges in https://github.com/pyenv/pyenv/pull/2635
* Add CPython 3.12.0a6 by @saaketp in https://github.com/pyenv/pyenv/pull/2638
## Release 2.3.14
* Fix indentation by @rafrafek in https://github.com/pyenv/pyenv/pull/2620
* Support for "BusyBox version" of "head" by @schuellerf in https://github.com/pyenv/pyenv/pull/2629
* bpo-27987 for v3.5.10 and v3.6.15: align by 16bytes on 64bit platforms by @chaimleib in https://github.com/pyenv/pyenv/pull/2630
* bpo-36231 for v3.5.10: fix Unsupported MacOS X CPU type in ffi.h by @chaimleib in https://github.com/pyenv/pyenv/pull/2633
* README: clarify behavior of `pyenv latest` by @mrienstra in https://github.com/pyenv/pyenv/pull/2634
## Release 2.3.13
* Fix pyenv-latest to ignore virtualenvs by @native-api in https://github.com/pyenv/pyenv/pull/2608
* Show symlink contents in non-bare `pyenv versions' by @native-api in https://github.com/pyenv/pyenv/pull/2609
* Ignore virtualenvs in `pyenv latest' in a clean way by @native-api in https://github.com/pyenv/pyenv/pull/2610
* Fix link resolving in pyenv-versions by @laggardkernel in https://github.com/pyenv/pyenv/pull/2612
* Add CPython 3.11.2 by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/2615
* Add CPython 3.10.10 by @edgarrmondragon in https://github.com/pyenv/pyenv/pull/2616
* Add CPython 3.12.0a5 by @Afront in https://github.com/pyenv/pyenv/pull/2614
## Release 2.3.12
* Undefined name: do not forget self when accessing flavor by @cclauss in https://github.com/pyenv/pyenv/pull/2595
* Fix wrong libpython being linked to in MacOS by @native-api in https://github.com/pyenv/pyenv/pull/2596
* Fix `:latest` by @native-api in https://github.com/pyenv/pyenv/pull/2599
* Fix `pyenv which` to support auto-resolved prefixes by @native-api in https://github.com/pyenv/pyenv/pull/2601
* Add more recent build of nogil Python. by @colesbury in https://github.com/pyenv/pyenv/pull/2602
## Release 2.3.11
* Add CPython 3.12.0a4 by @Afront in https://github.com/pyenv/pyenv/pull/2590
* Add a script to add the latest miniforge and mambaforge versions by @smcgivern in https://github.com/pyenv/pyenv/pull/2560
* Add missing Miniforge/Mambaforge versions (4.10.2-0 - 22.9.0-3) by @smcgivern in https://github.com/pyenv/pyenv/pull/2591
* Fix using dependencies from Ports in FreeBSD that are not searched with pkg-config by @native-api in https://github.com/pyenv/pyenv/pull/2593
* Fix priority for user-supplied configure and make flags by (**_only set --enable-shared if user hasn't supplied --disable-shared_**) @native-api in https://github.com/pyenv/pyenv/pull/2592
* Fix a compilation error in 3.8.10+ and 3.9.5+ when linking against Op… by @native-api in https://github.com/pyenv/pyenv/pull/2594
## Release 2.3.10
* Remove stray newline after python-build installation by @tklauser in https://github.com/pyenv/pyenv/pull/2566
* Allow multiple versions for pyenv-install by @rockandska in https://github.com/pyenv/pyenv/pull/2568
* --enable-shared by default by @anton-petrov in https://github.com/pyenv/pyenv/pull/2554
* Fix non-bash output while detecting shell by @ianchen-tw in https://github.com/pyenv/pyenv/pull/2561
* add pypy 7.3.11 release by @dand-oss in https://github.com/pyenv/pyenv/pull/2576
* Mention how to build for maximum performance by @hauntsaninja in https://github.com/pyenv/pyenv/pull/2579
* Add miniconda 22.11.1-1 by @aphedges in https://github.com/pyenv/pyenv/pull/2583
* Add Fig as autocomplete suggestion by @brendanfalk in https://github.com/pyenv/pyenv/pull/2574
* Fix using dependencies from Ports in BSD with no pkg-config by @native-api in https://github.com/pyenv/pyenv/pull/2586
## Release 2.3.9
* Add -latest suffix to miniforge3 by @nwh in https://github.com/pyenv/pyenv/pull/2551
* Add PyPy 7.3.10 by @dand-oss in https://github.com/pyenv/pyenv/pull/2553
* Add miniforge3 and mambaforge 22.9.0-2 by @smcgivern in https://github.com/pyenv/pyenv/pull/2559
* Fix compilation error when building OpenSSL 1.1.1q in MacOS 11+ for 3.9.16 by @lisbethw1130 in https://github.com/pyenv/pyenv/pull/2558
* Add `openssl` patches for 3.7.15, 3.7.16, and 3.8.16 by @samdoran in https://github.com/pyenv/pyenv/pull/2564
* Add support for Anaconda3-2022.10 by @huypn12 in https://github.com/pyenv/pyenv/pull/2565
## Release 2.3.8
* Export detected shell environment in pyenv-init by @ianchen-tw in https://github.com/pyenv/pyenv/pull/2540
* Add CPython 3.12.0a3 by @saaketp in https://github.com/pyenv/pyenv/pull/2545
* Add CPython 3.11.1 by @anton-petrov in https://github.com/pyenv/pyenv/pull/2549
* Add CPython 3.10.9 by @rudisimo in https://github.com/pyenv/pyenv/pull/2544
* Add 3.7.16, 3.8.16, 3.9.16 by @chadac in https://github.com/pyenv/pyenv/pull/2550
## Release 2.3.7
* Add Python version 3.11 to the macOS build by @jbkkd in https://github.com/pyenv/pyenv/pull/2510
* Don't use Zlib from XCode SDK if a custom compiler is used by @native-api in https://github.com/pyenv/pyenv/pull/2516
* Change line endings from CRLF to LF by @hoang-himself in https://github.com/pyenv/pyenv/pull/2517
* Fix resolution of a name that's a prefix of another name by @native-api in https://github.com/pyenv/pyenv/pull/2521
* GitHub Workflows security hardening by @sashashura in https://github.com/pyenv/pyenv/pull/2511
* Add nushell to activate list by @theref in https://github.com/pyenv/pyenv/pull/2524
* Fix compilation error when building OpenSSL 1.1.1q in MacOS 11+ for 3.9.15 and 3.8.15 by @twangboy in https://github.com/pyenv/pyenv/pull/2520
* Add simple `.editorconfig` file by @aphedges in https://github.com/pyenv/pyenv/pull/2518
* Support `aria2c` being a snap by @native-api in https://github.com/pyenv/pyenv/pull/2528
* Add CPython 3.12.0a2 by @saaketp in https://github.com/pyenv/pyenv/pull/2527
* Add --no-push-path option by @isaacl in https://github.com/pyenv/pyenv/pull/2526
* Fix typo in README.md by @weensy in https://github.com/pyenv/pyenv/pull/2535
* Copy auto installer oneliner to readme by @spookyuser in https://github.com/pyenv/pyenv/pull/2538
## Release 2.3.6
* Add CPython 3.10.8 (#2480)
* Add CPython 3.7.15, 3.8.15, and 3.9.15 (#2482)
* Add CPython 3.11.0 (#2493)
* Add CPython 3.12.0a1 (#2495)
* Add graalpy-22.3.0 (#2497)
* Auto-resolve prefixes to the latest version (#2487)
* It must be a full prefix -- the actual searched prefix is `<prefix>[-.]`
* Other flavors are likely sorted incorrectly atm
* Prereleases and versions with some suffixes (`-dev`, `-src`, `-latest`) are not searched
*`pyenv uninstall` has been excluded from the resolution feature: deleting a dynamically selected installation could be problematic
* Fix OpenSSL 1.1.1q compilation error in MacOS 11+ (#2500)
* Link to Tcl/Tk from Homebrew via pkgconfig for 3.11+ (#2501)
* Fix syntax error in `pyenv init -` if PYENV_ROOT has spaces (#2506)
## Release 2.3.5
* Add CPython 3.10.7 (#2454)
* Docs: update Fish PATH update (#2449)
* Add CPython 3.7.14, 3.8.14 and 3.9.14 (#2456)
* Update miniconda3-3.9-4.12.0 (#2460)
* Add CPython 3.11.0rc2 (#2459)
* Add patches for 3.7.14 to support Apple Silicon (#2463)
* Add ability to skip all use of Homebrew (#2464)
* Drop Travis integration (#2468)
* Build CPython 3.12+ with --with-dsymutil in MacOS (#2471)
* Add Pyston 2.3.5 (#2476)
## Release 2.3.4
* Add CPython 3.11.0rc1 (#2434)
* Add support for multiple versions in `pyenv uninstall` (#2432)
* Add micropython 1.18 and 1.19.1 (#2443)
* CI: support Micropython, deleted scripts; build with -v (#2447)
* Re-allow paths in .python-version while still preventing CVE-2022-35861 (#2442)
* CI: Bump OS versions (#2448)
* Add Cinder 3.8 (#2433)
## Release 2.3.3
* Use version sort in `pyenv versions` (#2405)
* Add CPython 3.11.0b4 (#2411)
* Python-build: Replace deprecated git protocol use with https in docs (#2413)
* Fix relative path traversal due to using version string in path (#2412)
* Allow pypy2 and pypy3 patching (#2421, #2419)
* Add CPython 3.11.0b5 (#2420)
* Add GraalPython 22.2.0 (#2425)
* Add CPython 3.10.6 (#2428)
## Release 2.3.2
* Add CPython 3.11.0b2 (#2380)
* Honor CFLAGS_EXTRA for MicroPython #2006 (#2007)
* Add post-install checks for curses, ctypes, lzma, and tkinter (#2353)
* Add CPython 3.11.0b3 (#2382)
* Add flags for Homebrew into `python-config --ldflags` (#2384)
* Add CPython 3.10.5 (#2386)
* Add Anaconda 2019.10, 2021.04, 2022.05; support Anaconda in add_miniconda.py (#2385)
Like `git`, the `pyenv` command delegates to subcommands based on its
first argument.
first argument.
The most common subcommands are:
* [`pyenv help`](#pyenv-help)
* [`pyenv commands`](#pyenv-commands)
* [`pyenv local`](#pyenv-local)
* [`pyenv global`](#pyenv-global)
@@ -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`
@@ -185,7 +198,7 @@ or, if you prefer 3.3.3 over 2.7.6,
## `pyenv install`
Install a Python version (using `python-build`).
Install a Python version (using [`python-build`](https://github.com/pyenv/pyenv/tree/master/plugins/python-build)).
Usage: pyenv install [-f] [-kvp] <version>
pyenv install [-f] [-kvp] <definition-file>
@@ -203,12 +216,38 @@ Install a Python version (using `python-build`).
-p/--patch Apply a patch from stdin before building
-g/--debug Build a debug version
To list the all available versions of Python, including Anaconda, Jython, pypy, and stackless, use:
$ pyenv install --list
Then install the desired versions:
$ pyenv install 2.7.6
$ pyenv install 2.6.8
$ pyenv versions
system
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
@@ -255,6 +294,8 @@ you run the given command.
$ pyenv which python3.3
/home/yyuu/.pyenv/versions/3.3.3/bin/python3.3
Use --nosystem argument in case when you don't need to search command in the
system environment.
## `pyenv whence`
@@ -265,23 +306,96 @@ Lists all Python versions with the given command installed.
2.7.6
3.3.3
## `pyenv exec`
## `pyenv install`
Usage: pyenv exec <command> [arg1 arg2...]
Part of [Python-build](https://github.com/yyuu/pyenv/tree/master/plugins/python-build), this installs versions of python
Runs an executable by first preparing PATH so that the selected Python
version's `bin` directory is at the front.
$ pyenv install 2.7.6
$ pyenv install 2.6.8
$ pyenv versions
system
2.6.8
* 2.7.6 (set by /home/yyuu/.pyenv/version)
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.
* Be extra careful when submitting logic specific for the Apple Silicon platform
As of this writing, Github Actions do not support it and only one team member has the necessary hardware.
So we may be unable to test your changes and may have to take your word for it.
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.
The release of the new version of Pyenv is done via GitHub Releases.
Release checklist:
* Start [drafting a new release on GitHub](https://github.com/pyenv/pyenv/releases) to generate a summary of changes. Save the summary locally.
* The summary may need editing. E.g. rephrase entries, delete/merge entries that are too minor or irrelevant to the users (e.g. typo fixes, CI)
* Push the version number in `libexec/pyenv---version`
* Minor version is pushed if there are significant functional changes (not e.g. bugfixes/formula adaptations/supporting niche use cases).
* Major version is pushed if there are breaking changes
* Update `CHANGELOG.md` with the new version number and the edited summary (only the changes section), reformatting it like the rest of the changelog sections
* Commit the changes locally into `master`
* Create a new tag with the new version number and push the changes including the tag
* Create a new release on GitHub based on the tag, using the saved summary
[](https://gitter.im/yyuu/pyenv?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
**NOTE:** If you want to use proxy for download, please set the `http_proxy` and `https_proxy`
environment variables.
**NOTE:** If you'd like a faster interpreter at the cost of longer build times,
see [_Building for maximum performance_ in Python-Build's README](plugins/python-build/README.md#building-for-maximum-performance).
#### Prefix auto-resolution to the latest version
All Pyenv subcommands except `uninstall` automatically resolve full prefixes to the latest version in the corresponding version line.
`pyenv install` picks the latest known version, while other subcommands pick the latest installed version.
E.g. to install and then switch to the latest 3.10 release:
```sh
pyenv install 3.10
pyenv global 3.10
```
You can run [`pyenv latest -k <prefix>`](COMMANDS.md#pyenv-latest) to see how `pyenv install` would resolve a specific prefix, or [`pyenv latest <prefix>`](COMMANDS.md#pyenv-latest) to see how other subcommands would resolve it.
See the [`pyenv latest` documentation](COMMANDS.md#pyenv-latest) for details.
#### Python versions with extended support
For the following Python releases, Pyenv applies user-provided patches that add support for some newer environments.
Though we don't actively maintain those patches, since existing releases never change,
it's safe to assume that they will continue working until there are further incompatible changes
To select a Pyenv-installed Python as the version to use, run one
of the following commands:
* [`pyenv shell <version>`](COMMANDS.md#pyenv-shell) -- select just for current shell session
* [`pyenv local <version>`](COMMANDS.md#pyenv-local) -- automatically select whenever you are in the current directory (or its subdirectories)
* [`pyenv global <version>`](COMMANDS.md#pyenv-shell) -- select globally for your user account
E.g. to select the above-mentioned newly-installed Python 3.10.4 as your preferred version to use:
~~~bash
pyenv global 3.10.4
~~~
Now whenever you invoke `python`, `pip` etc., an executable from the Pyenv-provided
3.10.4 installation will be run instead of the system Python.
Using "`system`" as a version name would reset the selection to your system-provided Python.
See [Understanding shims](#understanding-shims) and
[Understanding Python version selection](#understanding-python-version-selection)
for more details on how the selection works and more information on its usage.
### Uninstall Python versions
As time goes on, you will accumulate Python versions in your
`$(pyenv root)/versions` directory.
To remove old Python versions, use [`pyenv uninstall <versions>`](COMMANDS.md#pyenv-uninstall).
Alternatively, you can simply `rm -rf` the directory of the version you want
to remove. You can find the directory of a particular Python version
with the `pyenv prefix` command, e.g. `pyenv prefix 2.6.8`.
Note however that plugins may run additional operations on uninstall
which you would need to do by hand as well. E.g. Pyenv-Virtualenv also
removes any virtual environments linked to the version being uninstalled.
### Other operations
Run `pyenv commands` to get a list of all available subcommands.
Run a subcommand with `--help` to get help on it, or see the [Commands Reference](COMMANDS.md).
Note that Pyenv plugins that you install may add their own subcommands.
## Upgrading
### Upgrading with Homebrew
If you've installed Pyenv using Homebrew, upgrade using:
```sh
brew upgrade pyenv
```
To switch from a release to the latest development head of Pyenv, use:
```sh
brew uninstall pyenv
brew install pyenv --head
```
then you can upgrade it with `brew upgrade pyenv` as usual.
### Upgrading with Installer or Git checkout
If you've installed Pyenv with Pyenv-installer, you likely have the
[Pyenv-Update](https://github.com/pyenv/pyenv-update) plugin that would
upgrade Pyenv and all installed plugins:
```sh
pyenv update
```
If you've installed Pyenv using Pyenv-installer or Git checkout, you can also
upgrade your installation at any time using Git.
To upgrade to the latest development version of pyenv, use `git pull`:
$ cd ~/.pyenv
$ git pull
```sh
cd $(pyenv root)
git pull
```
To upgrade to a specific release of pyenv, check out the corresponding tag:
To upgrade to a specific release of Pyenv, check out the corresponding tag:
$ cd ~/.pyenv
$ git fetch
$ git tag
v0.1.0
$ git checkout v0.1.0
```sh
cd $(pyenv root)
git fetch
git tag
git checkout v0.1.0
```
### Uninstalling pyenv
## Uninstalling pyenv
The simplicity of pyenv makes it easy to temporarily disable it, or
uninstall from the system.
1. To **disable** pyenv managing your Python versions, simply remove the
`pyenv init` line from your shell startup configuration. This will
remove pyenv shims directory from PATH, and future invocations like
`python` will execute the system Python version, as before pyenv.
1. To **disable** Pyenv managing your Python versions, simply remove the
`pyenv init` invocations from your shell startup configuration. This will
remove Pyenv shims directory from `PATH`, and future invocations like
`python` will execute the system Python version, as it was before Pyenv.
`pyenv` will still be accessible on the command line, but your Python
apps won't be affected by version switching.
`pyenv` will still be accessible on the command line, but your Python
apps won't be affected by version switching.
2. To completely **uninstall** pyenv, perform step (1) and then remove
its root directory. This will **delete all Python versions** that were
installed under `` `pyenv root`/versions/ `` directory:
2. To completely **uninstall** Pyenv, remove _all_ Pyenv configuration lines
from your shell startup configuration, and then remove
its root directory. This will **delete all Python versions** that were
installed under the `` $(pyenv root)/versions/ `` directory:
rm -rf `pyenv root`
```sh
rm -rf $(pyenv root)
```
If you've installed pyenv using a package manager, as a final step
perform the pyenv package removal. For instance, for Homebrew:
If you've installed Pyenv using a package manager, as a final step,
perform the Pyenv package removal. For instance, for Homebrew:
brew uninstall pyenv
## Command Reference
### Homebrew on Mac OS X
You can also install pyenv using the [Homebrew](http://brew.sh)
package manager for Mac OS X.
$ brew update
$ brew install pyenv
```
brew uninstall pyenv
```
To upgrade pyenv in the future, use `upgrade` instead of `install`.
## Pyenv plugins
After installation, you'll need to add `eval "$(pyenv init -)"` to your profile (as stated in the caveats displayed by Homebrew — to display them again, use `brew info pyenv`). You only need to add that to your profile once.
Pyenv provides a simple, flexible and maintainable way to extend and customize its functionality with plugins --
as simple as creating a plugin directory and dropping a shell script on a certain subpath of it
with whatever extra logic you need to be run at certain moments.
Then follow the rest of the post-installation steps under "Basic GitHub Checkout" above, starting with #4 ("restart your shell so the path changes take effect").
See [_Plugins_ on the wiki](https://github.com/pyenv/pyenv/wiki/Plugins) on how to install and use plugins
as well as a catalog of some useful existing plugins for common needs.
### Advanced Configuration
See [_Authoring plugins_ on the wiki](https://github.com/pyenv/pyenv/wiki/Authoring-plugins) on writing your own plugins.
## Advanced Configuration
Skip this section unless you must know what every line in your shell
profile is doing.
`pyenv init` is the only command that crosses the line of loading
extra commands into your shell. Coming from rvm, some of you might be
opposed to this idea. Here's what `pyenv init` actually does:
Also see the [Environment variables](#environment-variables) section
for the environment variables that control Pyenv's behavior.
1. **Sets up your shims path.** This is the only requirement for pyenv to
function properly. You can do this by hand by prepending
`~/.pyenv/shims` to your `$PATH`.
`pyenv init` is the only command that crosses the line of loading
extra commands into your shell. Coming from RVM, some of you might be
opposed to this idea. Here's what `eval "$(pyenv init -)"` actually does:
1. **Sets up the shims path.** This is what allows Pyenv to intercept
and redirect invocations of `python`, `pip` etc. transparently.
It prepends `$(pyenv root)/shims` to your `$PATH`.
It also deletes any other instances of `$(pyenv root)/shims` on `PATH`
which allows to invoke `eval "$(pyenv init -)"` multiple times without
getting duplicate `PATH` entries.
2. **Installs autocompletion.** This is entirely optional but pretty
useful. Sourcing `~/.pyenv/completions/pyenv.bash` will set that
up. There is also a `~/.pyenv/completions/pyenv.zsh` for Zsh
users.
useful. Sourcing `$(pyenv root)/completions/pyenv.bash` will set that
up. There are also completions for Zsh and Fish.
3. **Rehashes shims.** 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 `pyenv rehash` manually.
4. **Installs the sh dispatcher.** This bit is also optional, but allows
pyenv and plugins to change variables in your current shell, making
commands like `pyenv shell` possible. The sh dispatcher doesn't do
4. **Installs `pyenv` into the current shell as a shell function.**
This bit is also optional, but allows
pyenv and plugins to change variables in your current shell.
This is required for some commands like `pyenv shell` to work.
The sh dispatcher doesn't do
anything crazy like override `cd` or hack your shell prompt, but if
for some reason you need `pyenv` to be a real script rather than a
shell function, you can safely skip it.
To see exactly what happens under the hood for yourself, run `pyenv init -`.
`eval "$(pyenv init --path)"` only does items 1 and 3.
To see exactly what happens under the hood for yourself, run `pyenv init -`
or `pyenv init --path`.
`eval "$(pyenv init -)"` is supposed to run at any interactive shell's
startup (including nested shells -- e.g. those invoked from editors)
so that you get completion and convenience shell functions.
`eval "$(pyenv init --path)"` can be used instead of `eval "$(pyenv init -)"`
to just enable shims, without shell integration. It can also be used to bump shims
to the front of `PATH` after some other logic has prepended stuff to `PATH`
that may shadow Pyenv's shims.
* In particular, in Debian-based distributions, the stock `~/.profile`
prepends per-user `bin` directories to `PATH` after having sourced `~/.bashrc`.
This necessitates appending a `pyenv init` call to `~/.profile` as well as `~/.bashrc`
in these distributions because the system's Pip places executables for
modules installed by a non-root user into those per-user `bin` directories.
### Uninstalling Python Versions
### Using Pyenv without shims
As time goes on, you will accumulate Python versions in your
`~/.pyenv/versions` directory.
If you don't want to use `pyenv init` and shims, you can still benefit
from pyenv's ability to install Python versions for you. Just run
`pyenv install` and you will find versions installed in
`$(pyenv root)/versions`.
To remove old Python versions, `pyenv uninstall` command to automate
the removal process.
You can manually execute or symlink them as required,
or you can use [`pyenv exec <command>`](COMMANDS.md#pyenv-exec)
whenever you want `<command>` to be affected by Pyenv's version selection
as currently configured.
Alternatively, simply `rm -rf` the directory of the version you want
to remove. You can find the directory of a particular Python version
with the `pyenv prefix` command, e.g. `pyenv prefix 2.6.8`.
`pyenv exec` works by prepending `$(pyenv root)/versions/<selectedversion>/bin`
to `PATH` in the `<command>`'s environment, the same as what e.g. RVM does.
----
### Environment variables
## Command Reference
See [COMMANDS.md](COMMANDS.md).
----
## Environment variables
You can affect how pyenv operates with the following settings:
You can affect how Pyenv operates with the following environment variables:
name | default | description
-----|---------|------------
`PYENV_VERSION` | | Specifies the Python version to be used.<br>Also see [`pyenv shell`](#pyenv-shell)
`PYENV_ROOT` | `~/.pyenv` | Defines the directory under which Python versions and shims reside.<br>Also see `pyenv root`
`PYENV_VERSION` | | Specifies the Python version to be used.<br>Also see [`pyenv shell`](COMMANDS.md#pyenv-shell)
`PYENV_ROOT` | `~/.pyenv` | Defines the directory under which Python versions and shims reside.<br>Also see [`pyenv root`](COMMANDS.md#pyenv-root)
`PYENV_HOOK_PATH` | [_see wiki_][hooks] | Colon-separated list of paths searched for pyenv hooks.
`PYENV_DIR` | `$PWD` | Directory to start searching for `.python-version` files.
`PYTHON_BUILD_ARIA2_OPTS` | | Used to pass additional parameters to [`aria2`](https://aria2.github.io/).<br>If the `aria2c` binary is available on `PATH`, pyenv uses `aria2c` instead of `curl` or `wget` to download the Python Source code. If you have an unstable internet connection, you can use this variable to instruct `aria2` to accelerate the download.<br>In most cases, you will only need to use `-x 10 -k 1M` as value to `PYTHON_BUILD_ARIA2_OPTS` environment variable
See also [_Special environment variables_ in Python-Build's README](plugins/python-build/README.md#special-environment-variables)
for environment variables that can be used to customize the build.
pyenv lets you easily switch between multiple versions of Python\. It's simple, unobtrusive, and follows the UNIX tradition of single\-purpose tools that do one thing well\.
.P
To start using pyenv
.IP"1."3
\fBAppend\fR the following to \fB$HOME/.bashrc\fR
.P
.RS15
.nf
if command -v pyenv 1>/dev/null 2>&1; then\n
eval "$(pyenv init -)" \n
fi
.fi
.RE
.RS3
.P
.nh
Appending this line enables shims. Please make sure this line is placed toward the end of the shell configuration file since it manipulates \fBPATH\fR during the initialization\.
.hy
.TP13
.BDebiannote:
Modify only your \fB~/\.bashrc\fR file instead of creating
.br
\fB~/\.bash_profile\fR
.P
.RS0
\fBZsh note\fR: Modify your \fB~/\.zshrc\fR file instead of \fB~/\.bashrc\fR
.P
\fBWarning\fR: If you configured your system so that \fBBASH_ENV\fR variable points to \fB\.bashrc\fR\. You should almost certainly put the above mentioned line into \fB\.bash_profile\fR, and \fBnot\fR into \fB\.bashrc\fR. Otherwise you may observe strange behaviour, such as \fBpyenv\fR getting into an infinite loop. See #264
.URhttps://github\.com/pyenv/pyenv/issues/264
.UE
for details.
.RE
.RE
.IP"2."3
\fBRestart your shell so the path changes take effect\.\fR You can now begin using pyenv\.
.P
.RS15
exec "$SHELL"\fR
.RE
.IP"3."3
\fBInstall Python versions into \fB$(pyenv root)/versions\fR\.\fR For example, to download and install Python 3\.6\.12, run:
.P
.RS15
.Bpyenvinstall3.6.12\fR
.RE
.P
\fBNOTE:\fR If you need to pass configure option to build, please use \fBCONFIGURE_OPTS\fR environment variable. If you are having trouble installing a python version, please visit the wiki page about Common Build Problems
\fBProxy note\fR: If you use a proxy, export \fBHTTP_PROXY\fR and \fBHTTPS_PROXY\fR environment variables.
.P
.SS"Stop using pyenv"
The simplicity of pyenv makes it easy to temporarily disable it, or uninstall from the system\.
To \fBdisable\fR pyenv managing your Python versions, simply remove the \fBpyenv init\fR line from your shell startup configuration\. This will remove pyenv shims directory from PATH, and future invocations like \fBpython\fR will execute the system Python version, as before pyenv\.
.IP""0
.P
\fBpyenv\fR will still be accessible on the command line, but your Python apps won't be affected by version switching\.
.IP""0
.SHCOMMANDLINEOPTIONS
Like \fBgit\fR, the \fBpyenv\fR command delegates to subcommands based on its first argument\.
.SS"Some useful pyenv commands are:"
.TP5
.Bcommands
List all available pyenv commands
.TP
.Bexec
Run an executable with the selected Python version
.TP
.Bglobal
Set or show the global Python version(s)
.TP
.Bhelp
Display help for a command
.TP
.Bhooks
List hook scripts for a given pyenv command
.TP
.Binit
Configure the shell environment for pyenv
.TP
.Binstall
Install a Python version using python\-build
.TP
.Blocal
Set or show the local application\-specific Python version(s)
.TP
.Bprefix
Display prefix for a Python version
.TP
.Brehash
Rehash pyenv shims (run this after installing executables)
.TP
.Broot
Display the root directory where versions and shims are kept
.TP
.Bshell
Set or show the shell\-specific Python version
.TP
.Bshims
List existing pyenv shims
.TP
.Buninstall
Uninstall Python versions
.TP
.Bversion
Show the current Python version(s) and its origin
.TP
.Bversion\-file
Detect the file that sets the current pyenv version
.TP
.Bversion\-name
Show the current Python version
.TP
.Bversion\-origin
Explain how the current Python version is set
.TP
.Bversions
List all Python versions available to pyenv
.TP
.Bwhence
List all Python versions that contain the given executable
.TP
.Bwhich
Display the full path to an executable
.PP
See `pyenv help <command>' for information on a specific command.
For full documentation, see \fBCOMMAND REFERENCE\fR section
.SHOPTIONS
.TP
.B\-h,\-\-help
Show summary of options.
.TP
.B\-v,\-\-version
Show version of program.
.SHCOMPARISON
.P
.B"pyenvdoes\|\.\|\.\|\.
.P
.IP\(bu4
Let you \fBchange the global Python version\fR on a per\-user basis\.
.IP\(bu4
Provide support for \fBper\-project Python versions\fR\.
.IP\(bu4
Allow you to \fBoverride the Python version\fR with an environment variable\.
.IP\(bu4
Search commands from \fBmultiple versions of Python at a time\fR\. This may be helpful to test across Python versions with tox
.IP""0
.P
.B"In contrast with pythonbrew and pythonz, pyenv does not\|\.\|\.\|\."
.IP\(bu4
\fBDepend on Python itself\.\fR pyenv was made from pure shell scripts\. There is no bootstrap problem of Python\.
.IP\(bu4
\fBNeed to be loaded into your shell\.\fR Instead, pyenv's shim approach works by adding a directory to your \fB$PATH\fR\.
.IP\(bu4
\fBManage virtualenv\.\fR Of course, you can create virtualenv yourself, or pyenv\-virtualenv to automate the process\.
.SH"How It Works"
At a high level, pyenv intercepts Python commands using shim executables injected into your \fBPATH\fR, determines which Python version has been specified by your application, and passes your commands along to the correct Python installation\.
.SS"Understanding PATH"
When you run a command like \fBpython\fR or \fBpip\fR, your operating system searches through a list of directories to find an executable file with that name\. This list of directories lives in an environment variable called \fBPATH\fR, with each directory in the list separated by a colon:
.IP""4
.nf
/usr/local/bin:/usr/bin:/bin
.fi
.IP""0
.P
Directories in \fBPATH\fR are searched from left to right, so a matching executable in a directory at the beginning of the list takes precedence over another one at the end\. In this example, the \fB/usr/local/bin\fR directory will be searched first, then \fB/usr/bin\fR, then \fB/bin\fR\.
.SS"Understanding Shims"
pyenv works by inserting a directory of \fIshims\fR at the front of your \fBPATH\fR:
.IP""4
.nf
$(pyenv root)/shims:/usr/local/bin:/usr/bin:/bin
.fi
.IP""0
.P
Through a process called \fIrehashing\fR, pyenv maintains shims in that directory to match every Python command (\fBpython\fR,\fBpip\fR,etc...) across every installed version of Python
.P
Shims are lightweight executables that simply pass your command along to pyenv\. So with pyenv installed, when you run, say, \fBpip\fR, your operating system will do the following:
.IP\(bu4
Search your \fBPATH\fR for an executable file named \fBpip\fR
.IP\(bu4
Find the pyenv shim named \fBpip\fR at the beginning of your \fBPATH\fR
.IP\(bu4
Run the shim named \fBpip\fR, which in turn passes the command along to pyenv
.IP""0
.SS"Choosing the Python Version"
When you execute a shim, pyenv determines which Python version to use by reading it from the following sources, in this order:
.IP"1."4
The \fBPYENV_VERSION\fR environment variable (if specified)\. You can use the \fBpyenv shell\fR command to set this environment variable in your current shell session\.
.IP"2."4
The application\-specific \fB\.python\-version\fR file in the current directory (if present)\. You can modify the current directory's \fB\.python\-version\fR file with the \fBpyenv local\fR command\.
.IP"3."4
The first \fB\.python\-version\fR file found (if any) by searching each parent directory, until reaching the root of your filesystem\.
.IP"4."4
The global \fB$(pyenv root)/version\fR file\. You can modify this file using the \fBpyenv global\fR command\. If the global version file is not present, pyenv assumes you want to use the "system" Python\. (In other words, whatever version would run if pyenv weren't in your \fBPATH\fR\.)
.IP""0
.P
.nh
\fBNOTE:\fR You can activate multiple versions at the same time, including multiple versions of Python2 or Python3 simultaneously\. This allows for parallel usage of Python2 and Python3, and is required with tools like \fBtox\fR\. For example, to set your path to first use your \fBsystem\fR Python and Python3 (set to 2\.7\.9 and 3\.4\.2 in this example), but also have Python 3\.3\.6, 3\.2, and 2\.5 available on your \fBPATH\fR, one would first \fBpyenv install\fR the missing versions, then set \fBpyenv global system 3\.3\.6 3\.2 2\.5\fR\. At this point, one should be able to find the full executable path to each of these using \fBpyenv which\fR, e\.g\.\fBpyenv which python2\.5\fR (should display \fB$(pyenv root)/versions/2\.5/bin/python2\.5\fR), or \fBpyenv which python3\.4\fR (should display path to system Python3)\. You can also specify multiple versions in a \fB\.python\-version\fR file, separated by newlines or any whitespace\.
hy
.SS"Locating the Python Installation"
Once pyenv has determined which version of Python your application has specified, it passes the command along to the corresponding Python installation\.
.P
Each Python version is installed into its own directory under
.nf
\fB$(pyenv root)/versions\fR\.
.fi
.P
For example, you might have these versions installed:
.IP\(bu4
\fB$(pyenv root)/versions/2\.7\.8/\fR
.IP\(bu4
\fB$(pyenv root)/versions/3\.4\.2/\fR
.IP\(bu4
\fB$(pyenv root)/versions/pypy\-2\.4\.0/\fR
.IP""0
.P
As far as pyenv is concerned, version names are simply the directories in \fB$(pyenv root)/versions\fR\.
.SS"Managing Virtual Environments"
There is a pyenv plugin named pyenv\-virtualenv which comes with various features to help pyenv users to manage virtual environments created by virtualenv or Anaconda\. Because the \fBactivate\fR script of those virtual environments are relying on mutating \fB$PATH\fR variable of user's interactive shell, it will intercept pyenv's shim style command execution hooks\. We'd recommend to install pyenv\-virtualenv as well if you have some plan to play with those virtual environments\.
.SH"Advanced Configuration"
Skip this section unless you must know what every line in your shell profile is doing\.
.P
\fBpyenv init\fR is the only command that crosses the line of loading extra commands into your shell\. Coming from rvm, some of you might be opposed to this idea\. Here's what \fBpyenv init\fR actually does:
.IP"1."4
\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\.
.IP""0
.P
To see exactly what happens under the hood for yourself, run \fB"pyenv init \-"\fR\.
.SH"Uninstalling Python Versions"
As time goes on, you will accumulate Python versions in your \fB$(pyenv root)/versions\fR directory\.
.P
To remove old Python versions, \fBpyenv uninstall\fR command to automate the removal process\.
.P
Alternatively, simply \fBrm \-rf\fR the directory of the version you want to remove\. You can find the directory of a particular Python version with the \fBpyenv prefix\fR command,
.P
e\.g\.\fBpyenv prefix 2\.6\.8\fR\.
.SH"Command Reference"
.P
The most common subcommands are:
.SS"pyenv commands"
Lists all available pyenv commands\.
.SS"pyenv local"
Sets a local application\-specific Python version by writing the version name to a \fB\.python\-version\fR file in the current directory\. This version overrides the global version, and can be overridden itself by setting the \fBPYENV_VERSION\fR environment variable or with the \fBpyenv shell\fR command\.
.IP""4
.nf
$ pyenv local 2\.7\.6
.fi
.IP""0
.P
When run without a version number, \fBpyenv local\fR reports the currently configured local version\. You can also unset the local version:
.IP""4
.nf
$ pyenv local \-\-unset
.fi
.IP""0
.P
Previous versions of pyenv stored local version specifications in a file named \fB\.pyenv\-version\fR\. For backwards compatibility, pyenv will read a local version specified in an \fB\.pyenv\-version\fR file, but a \fB\.python\-version\fR file in the same directory will take precedence\.
.P
You can specify multiple versions as local Python at once\.
.P
Let's say if you have two versions of 2\.7\.6 and 3\.3\.3\. If you prefer 2\.7\.6 over 3\.3\.3,
.IP""4
.nf
$ pyenv local 2\.7\.6 3\.3\.3
$ pyenv versions
system
* 2\.7\.6 (set by /Users/yyuu/path/to/project/\.python\-version)
* 3\.3\.3 (set by /Users/yyuu/path/to/project/\.python\-version)
$ python \-\-version
Python 2\.7\.6
$ python2\.7 \-\-version
Python 2\.7\.6
$ python3\.3 \-\-version
Python 3\.3\.3
.fi
.IP""0
.P
or, if you prefer 3\.3\.3 over 2\.7\.6,
.IP""4
.nf
$ pyenv local 3\.3\.3 2\.7\.6
$ pyenv versions
system
* 2\.7\.6 (set by /Users/yyuu/path/to/project/\.python\-version)
* 3\.3\.3 (set by /Users/yyuu/path/to/project/\.python\-version)
venv27
$ python \-\-version
Python 3\.3\.3
$ python2\.7 \-\-version
Python 2\.7\.6
$ python3\.3 \-\-version
Python 3\.3\.3
.fi
.IP""0
.SS"pyenv global"
Sets the global version of Python to be used in all shells by writing the version name to the \fB~/\.pyenv/version\fR file\. This version can be overridden by an application\-specific \fB\.python\-version\fR file, or by setting the \fBPYENV_VERSION\fR environment variable\.
.IP""4
.nf
$ pyenv global 2\.7\.6
.fi
.IP""0
.P
The special version name \fBsystem\fR tells pyenv to use the system Python (detected by searching your \fB$PATH\fR)\.
.P
When run without a version number, \fBpyenv global\fR reports the currently configured global version\.
.P
You can specify multiple versions as global Python at once\.
.P
Let's say if you have two versions of 2\.7\.6 and 3\.3\.3\. If you prefer 2\.7\.6 over 3\.3\.3,
.IP""4
.nf
$ pyenv global 2\.7\.6 3\.3\.3
$ pyenv versions
system
* 2\.7\.6 (set by /Users/yyuu/\.pyenv/version)
* 3\.3\.3 (set by /Users/yyuu/\.pyenv/version)
$ python \-\-version
Python 2\.7\.6
$ python2\.7 \-\-version
Python 2\.7\.6
$ python3\.3 \-\-version
Python 3\.3\.3
.fi
.IP""0
.P
or, if you prefer 3\.3\.3 over 2\.7\.6,
.IP""4
.nf
$ pyenv global 3\.3\.3 2\.7\.6
$ pyenv versions
system
* 2\.7\.6 (set by /Users/yyuu/\.pyenv/version)
* 3\.3\.3 (set by /Users/yyuu/\.pyenv/version)
venv27
$ python \-\-version
Python 3\.3\.3
$ python2\.7 \-\-version
Python 2\.7\.6
$ python3\.3 \-\-version
Python 3\.3\.3
.fi
.IP""0
.SS"pyenv shell"
Sets a shell\-specific Python version by setting the \fBPYENV_VERSION\fR environment variable in your shell\. This version overrides application\-specific versions and the global version\.
.IP""4
.nf
$ pyenv shell pypy\-2\.2\.1
.fi
.IP""0
.P
When run without a version number, \fBpyenv shell\fR reports the current value of \fBPYENV_VERSION\fR\. You can also unset the shell version:
.IP""4
.nf
$ pyenv shell \-\-unset
.fi
.IP""0
.P
Note that you'll need pyenv's shell integration enabled (step 3 of the installation instructions) in order to use this command\. If you prefer not to use shell integration, you may simply set the \fBPYENV_VERSION\fR variable yourself:
.IP""4
.nf
$ export PYENV_VERSION=pypy\-2\.2\.1
.fi
.IP""0
.P
You can specify multiple versions via \fBPYENV_VERSION\fR at once\.
.P
Let's say if you have two versions of 2\.7\.6 and 3\.3\.3\. If you prefer 2\.7\.6 over 3\.3\.3,
.IP""4
.nf
$ pyenv shell 2\.7\.6 3\.3\.3
$ pyenv versions
system
* 2\.7\.6 (set by PYENV_VERSION environment variable)
* 3\.3\.3 (set by PYENV_VERSION environment variable)
$ python \-\-version
Python 2\.7\.6
$ python2\.7 \-\-version
Python 2\.7\.6
$ python3\.3 \-\-version
Python 3\.3\.3
.fi
.IP""0
.P
or, if you prefer 3\.3\.3 over 2\.7\.6,
.IP""4
.nf
$ pyenv shell 3\.3\.3 2\.7\.6
$ pyenv versions
system
* 2\.7\.6 (set by PYENV_VERSION environment variable)
* 3\.3\.3 (set by PYENV_VERSION environment variable)
venv27
$ python \-\-version
Python 3\.3\.3
$ python2\.7 \-\-version
Python 2\.7\.6
$ python3\.3 \-\-version
Python 3\.3\.3
.fi
.IP""0
.SS"pyenv install"
Install a Python version
.IP""4
.nf
Usage: pyenv install [\-f] [\-kvp] <version>
pyenv install [\-f] [\-kvp] <definition\-file>
pyenv install \-l|\-\-list
\-l, \-\-list List all available versions
\-f, \-\-force Install even if the version appears to be installed
already
\-s, \-\-skip\-existing Skip the installation if the version appears to be
installed already
python\-build options:
\-k, \-\-keep Keep source tree in $PYENV_BUILD_ROOT after installation
(defaults to $PYENV_ROOT/sources)
\-v, \-\-verbose Verbose mode: print compilation status to stdout
\-p, \-\-patch Apply a patch from stdin before building
\-g, \-\-debug Build a debug version
.fi
.IP""0
.P
To list the all available versions of Python, including Anaconda, Jython, pypy, and stackless, use:
\-f Attempt to remove the specified version without prompting
for confirmation\. If the version does not exist, do not
display an error message\.
.fi
.IP""0
.SS"pyenv rehash"
Installs shims for all Python binaries known to pyenv (i\.e\., \fB~/\.pyenv/versions/*/bin/*\fR)\. Run this command after you install a new version of Python, or install a package that provides binaries\.
.IP""4
.nf
$ pyenv rehash
.fi
.IP""0
.SS"pyenv version"
Displays the currently active Python version, along with information on how it was set\.
.IP""4
.nf
$ pyenv version
2\.7\.6 (set by /home/yyuu/\.pyenv/version)
.fi
.IP""0
.SS"pyenv versions"
Lists all Python versions known to pyenv, and shows an asterisk next to the currently active version\.
.IP""4
.nf
$ pyenv versions
2\.5\.6
2\.6\.8
* 2\.7\.6 (set by /home/yyuu/\.pyenv/version)
3\.3\.3
jython\-2\.5\.3
pypy\-2\.2\.1
.fi
.IP""0
.SS"pyenv which"
Displays the full path to the executable that pyenv will invoke when you run the given command\.
Lists all Python versions with the given command installed\.
.IP""4
.nf
$ pyenv whence 2to3
2\.6\.8
2\.7\.6
3\.3\.3
.fi
.IP""0
.SH"Environment variables"
You can affect how pyenv operates with the following settings:
.TP28
.Bname(default)
.Bdescription
.TP28
.BPYENV_VERSION
Specifies the Python version to be used. Also see \fBpyenv shell\fR
.TP
.BPYENV_ROOT(\fB~/.pyenv\fR)
Defines the directory under which Python versions and shims reside. Also see \fBpyenv root\fR
.TP
.BPYENV_DEBUG
Outputs debug information.
.br
Also as: \fBpyenv --debug <subcommand>\fR
.TP
.BPYENV_HOOK_PATH
Colon\-separated list of paths searched for pyenv hooks\.
.TP
.BPYENV_DIR(\fB$PWD\fR)
Directory to start searching for \fB\.python\-version\fR files\.
.TP
.BHTTP_PROXY,HTTPS_PROXY
Proxy Variables
.TP
.BCONFIGURE_OPTS
Pass configure options to build.
.TP
.BPYTHON_BUILD_ARIA2_OPTS
Used to pass additional parameters to \fBaria2\fR
.URhttps://aria2\.github\.io/
.UE
If the \fBaria2c\fR binary is available on PATH, pyenv uses \fBaria2c\fR instead of \fBcurl\fR or \fBwget\fR to download the Python Source code\. If you have an unstable internet connection, you can use this variable to instruct \fBaria2\fR to accelerate the download\.
In most cases, you will only need to use \fB\-x 10 \-k 1M\fR as value to \fBPYTHON_BUILD_ARIA2_OPTS\fR environment variable
python-build is a [pyenv](https://github.com/yyuu/pyenv) plugin that
python-build is a [pyenv](https://github.com/pyenv/pyenv) plugin that
provides a `pyenv install` command to compile and install different versions
of Python on UNIX-like systems.
You can also use python-build without pyenv in environments where you need
precise control over Python version installation.
See the [list of releases](https://github.com/yyuu/pyenv/releases)
See the [list of releases](https://github.com/pyenv/pyenv/releases)
for changes in each version.
## Installation
### Installing as an pyenv plugin (recommended)
### Installing as a pyenv plugin (recommended)
You need nothing to do since python-build is bundled with pyenv by
default.
Since python-build is bundled with pyenv by
default, you do not need to do anything.
### Installing as a standalone program (advanced)
@@ -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/yyuu/pyenv.git
git clone https://github.com/pyenv/pyenv.git
cd pyenv/plugins/python-build
./install.sh
@@ -55,7 +55,7 @@ Or, if you would like to install the latest development release:
## Usage
Before you begin, you should ensure that your build environment has the proper
system dependencies for compiling the wanted Python Version (see our [recommendations](https://github.com/yyuu/pyenv/wiki#suggested-build-environment)).
system dependencies for compiling the wanted Python Version (see our [recommendations](https://github.com/pyenv/pyenv/wiki#suggested-build-environment)).
### Using `pyenv install` with pyenv
@@ -93,10 +93,53 @@ Both `pyenv install` and `python-build` accept a path to a custom definition fil
in place of a version name. Custom definitions let you develop and install
versions of Python that are not yet supported by python-build.
See the [python-build built-in definitions](https://github.com/yyuu/pyenv/tree/master/plugins/python-build/share/python-build) as a starting point for
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.
##### 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
@@ -109,8 +152,14 @@ You can set certain environment variables to control the build process.
downloaded package files.
*`PYTHON_BUILD_MIRROR_URL` overrides the default mirror URL root to one of your
choosing.
*`PYTHON_BUILD_MIRROR_URL_SKIP_CHECKSUM`, if set, does not append the SHA2
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_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_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
@@ -124,7 +173,7 @@ You can set certain environment variables to control the build process.
*`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 buildling CPython. These variables
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).
install_package "Python-2.1.3" "https://www.python.org/ftp/python/2.1.3/Python-2.1.3.tgz#1bcb5bb587948bc38f36db60e15c376009c56c66570e563a08a82bf7f227afb9" standard verify_py21
install_package "Python-2.2.3" "https://www.python.org/ftp/python/2.2.3/Python-2.2.3.tgz#a8f92e6b89d47359fff0d1fbfe47f104afc77fd1cd5143e7332758b7bc100188" standard verify_py22
install_package "Python-2.3.7" "https://www.python.org/ftp/python/2.3.7/Python-2.3.7.tgz#969a9891dce9f50b13e54f9890acaf2be66715a5895bf9b11111f320c205b90e" standard verify_py23
install_package "Python-2.4" "https://www.python.org/ftp/python/2.4/Python-2.4.tgz#ff746de0fae8691c082414b42a2bb172da8797e6e8ff66c9a39d2e452f7034e9" standard verify_py24
install_package "Python-2.4.1" "https://www.python.org/ftp/python/2.4.1/Python-2.4.1.tgz#f449c3b167389324c525ad99d02376c518ac11e163dbbbc13bc88a5c7101fd00" standard verify_py24
install_package "Python-2.4.2" "https://www.python.org/ftp/python/2.4.2/Python-2.4.2.tgz#2653e1846e87fd9b3ee287fefc965c80c54646548b4913a22265b0dd54493adf" standard verify_py24
install_package "Python-2.4.3" "https://www.python.org/ftp/python/2.4.3/Python-2.4.3.tgz#985a413932f5e31e6280b37da6b285a3a0b2748c6786643989ed9b23de97e2d5" standard verify_py24
install_package "Python-2.4.4" "https://www.python.org/ftp/python/2.4.4/Python-2.4.4.tgz#92be6e20cbc3111d9dd0c016d72ef7914c23b879dc52df7ba28df97afbf12e2e" standard verify_py24
install_package "Python-2.4.5" "https://www.python.org/ftp/python/2.4.5/Python-2.4.5.tgz#6ae6f67a388a7f70ed3a20eebab5aae995ee433089d1f1724095c62f4b7389a1" standard verify_py24
install_package "Python-2.4.6" "https://www.python.org/ftp/python/2.4.6/Python-2.4.6.tgz#b03f269e826927f05c966cf4f4414f3c93ee2314960859e7f8375e24e82f8b02" standard verify_py24
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-2.7.6" "https://www.python.org/ftp/python/2.7.6/Python-2.7.6.tgz#99c6860b70977befa1590029fae092ddb18db1d69ae67e8b9385b66ed104ba58" standard verify_py27 copy_python_gdb ensurepip
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.
