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."
The README details `eval`ing `rbenv init -`, but for some shells (such as fish) there's a difference in what should be run. It turns out that `rbenv init` on its own will print correct instructions, so we should point users to running that command instead.
It seems rbenv now comes with ruby-build. I have not investigated fully, but the previously shown command: `brew install rbenv ruby-build` caused issues on my machine. After uninstalling both and simply running `brew install rbenv` everything worked fine.
```
/home/yyuu/.pyenv/versions/3.2.6/lib/python3.2/site-packages/pkg_resources/__init__.py:85: UserWarning: Support for Python 3.0-3.2 has been dropped. Future versions will fail here.
warnings.warn(msg)
```
`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
`default` was made legacy back in 2011 with
5be66da9f4 (the command was renamed from
`rbenv-default` to `rbenv-global`, and so the global file was renamed
from `$RBENV_ROOT/default` to `$RBENV_ROOT/global` (the latter taking
precedence)
`global` was then made legacy about a month later in Sep 2011 when the
preferred filename was changed to `$RBENV_ROOT/version`.
This compiles the `realpath` dynamic extension for bash which speeds up
symlink resolution. If the extension doesn't compile due to
cross-platform issues, rbenv will still work normally, although not as fast.
When invoked from a shell script, `$(rbenv init -)` did not get the
shell name correct.
It needs to look at the `args` value from `ps`.
Ref: https://github.com/yyuu/pyenv/issues/373
The `../libexec` dance isn't necessary here. It was only necessary in
main `rbenv` command because that one might have been pointed to
directly via a symlink.
It doesn't try to chdir into RBENV_ROOT anymore because that might be
a location of an unrelated rbenv install that might have a different
version than the current one that is installed e.g. via a package
manager such as Homebrew.
Now just tries the repo where the source files (`libexec/*`) are
located, and if that isn't a valid rbenv repo, bail out early.
Expose a `version-origin` hook.
It is invoked *before* the traditional `rbenv-version-file` lookup. Because `version-origin` is traditionally run immediately after `version-name`, then any plugin hooks that alter `version-name` would have done so. Thus, running `version-origin` prior to printing the origin gives those plugins a chance to alter the `version-origin` to match.
If any of the hooks set `$RBENV_VERSION_ORIGIN`, then it is used as the return value. Otherwise, the existing logic continues to return "environment variable" or "filename" as appropriate.
This change, in conjunction with the `version-name` hook, makes a clean seam by which plugins can inject their own ruby version setting logic. Using this seam, as opposed to altering `$RBENV_COMMAND_PATH` from the `which` hook, means that the version name and origin are set more reliably and so `version`, `version-name`, `version-origin` and `which` all work as expected. Indeed, even PS1 works now.
Expose a `version-name` hook.
It is invoked *after* the traditional `RBENV_VERSION` lookup. Which means hook scripts can interrogate `$RBENV_VERSION_FILE` and/or `$RBENV_VERSION` (or use the executables).
The hooks are then run, giving plugins a chance to alter `RBENV_VERSION`. Once the hooks have run, we now have (in `$RBENV_VERSION`) the actual version we want to use (or it's empty which defaults to `system` per normal). Lastly, the same logic remains for checking if the version exists, or trimming the `ruby-` prefix.
Prime example: the ruby-bundler-ruby-version plugin can select a ruby by using the `ruby` directive from the `Gemfile` if a local `.ruby-version` doesn't exist.
Can be used for `.ruby-version` file lookup in the ancestry of a
specific directory. In this mode of operation, global version files
aren't taken into consideration, and the command fails unless a local
version file was found.
This new test was creating an (intentionally invalid) .ruby-version file
in current working directory; typically the rbenv project dir.
Immediately after test runs, I had a leftover .ruby-version file.
The version-file tests create and cd into the RBENV_TEST_DIR as part of
setup(). I'm using the same directory for this test fix, but am only
using it for this particular test. None of the other exec tests seem to
need to be in a temp test dir, so no use putting it in setup().
If subcommand is provided (and exists) and its first arg is -h/--help,
go ahead and intercept the call; redirecting to rbenv-help <subcommand>
This means subcommands and plugins need not handle --help flag
themselves
- Explicitly asking for help with `-h` or `--help` exits with 0 status
and displays help on stdout.
- Not providing any arguments to rbenv results in failure status and
displays version and help on stderr.
Adding a tip for how to view the Homebrew package caveats again if you skipped reading them.
Directing readers to additional next steps after installing pyenv via Homebrew.
Many advanced users who enjoy reading detailed documentation may not really think of themselves as "neckbeards", even in a jokey way, so naming this section with a simple, familiar (and easy-to-translate!) name may encourage more people to read it. :)
Correcting instructions for installing Python versions (removing "download and unpack the source").
Fixing links to #pyenv-shell, #pyenv-local, and #pyenv-global - linking them to the appropriate sections of the COMMANDS.md page.
If `foo` didn't exist and `RBENV_VERSION=system rbenv which foo` was
called, the error message used to be misleading:
rbenv: version `system' is not installed
Instead, have the error message simply say that the command was not found.
Fixes#770
Useful in combination with `--bare` to list just the unique version
numbers without the extra directory entries that are symlinks to other
version numbers in the same directory.
This is for Linux desktop platforms that have Terminal application
configured to start shells in interactive but not login mode. Creating a
`~/.bash_profile` would also cause `~/.profile` to not run, which might
be a problem on Ubuntu which ships with a default `~/.profile`.
This avoids running `rbenv rehash` after installing libraries that don't
have executables, or after a no-op `bundle install` that didn't install
anything.
This is an attempt to work around the fact that Rubygems post_install
hooks may happen multiple times per single `bundle install` and ideally
we want `rbenv rehash` to run only once if new gems have been installed.
However, due to Bundler parallelism using `fork` on platforms that
support it, it's impossible for the child processes to communicate with
the master process to signal it to run `rbenv rehash` in the end.
This hooks into Bundler `install` command and runs `rbenv rehash` after
all gems have finished installing, but only if the install location was
system gems location and not a custom path (such as per-project
`vendor/bundle`).
This is limited because we can't tell whether any gems have been
installed at all, let alone do those gems have executables. However it's
better than having multiple `rbenv rehash` being run in parallel and
outputting confusing error messages as a result.
When `rbenv --version` is called, this now happens:
1. It changes into the directory where `libexec/rbenv--version` resides
and checks if it's a checkout of the rbenv repo (as opposed to
Homebrew checkout or something else). Then it reads the git revision.
2. If that failed, change to `$RBENV_ROOT` directory and repeat step 1.
If set by the user's environment, `git config --global` writes will go
to that destination instead of temporary $HOME. We definitely don't want
that.
Fixes#742
This is required for the shims to handle `#!/usr/bin/env python3` in a
shebang, just like `python` is handled currently: it will set
`PYENV_DIR` to the root of the invoked script, which is required for a
`.python-version` script to get picked up from there.
This was rejected for rbenv, where it does not make much sense
(https://github.com/sstephenson/rbenv/pull/735).
Ref: https://github.com/yyuu/pyenv/pull/368#issuecomment-102806837
It's not that this is a preferred way to set a global version (one
should use `rbenv global <version>` instead), but this fixes the
function purely for correctness: all parent directories should be
scanned, even the root directory.
Fixes#745
I was seeing the following occasionally in scripts:
> …/.pyenv/libexec/pyenv-version-file-read: line 12: type: write error: Broken pipe
This patch hopefully improves/fixes this, and it seems better anyway to
just use sed here.
This merges
4d72eefffc
to build a common ancestor for future merges.
This is branched off f48a5b11d7, which was
the last manual merge.
Discussion / initial idea: https://github.com/yyuu/pyenv/pull/286#issuecomment-66565475
This was done using:
# Keep our changes for "unmerged, both added"
for i in $(git status --porcelain | grep '^AA ' | cut -d\ -f2); do
git checkout --ours $i
git add $i
done
# "git mv" rbenv files to our name, keeping the current contents.
for i in $(git status --porcelain | grep '^A ' | sed 's/^A //'); do
ours=${i//rbenv/pyenv}
test -f $ours || { echo "Skipping: $i"; continue; }
git mv -f $i $ours
git reset HEAD $ours
done
I've handled the following then manually:
- rbenv.d/exec/gem-rehash.bash
- rbenv.d/exec/gem-rehash/rubygems_plugin.rb
This should allow to merge rbenv in the future using:
git merge rbenv/master -s recursive -X rename-threshold=5%
I am not sure about the rename-threshold, 25% also worked for one file
I've tested.
Conflicts:
.gitignore
.travis.yml
LICENSE
README.md
src/Makefile.in
test/--version.bats
test/commands.bats
test/completions.bats
test/exec.bats
test/global.bats
test/help.bats
test/hooks.bats
test/init.bats
test/local.bats
test/prefix.bats
test/rehash.bats
test/run
test/shell.bats
test/shims.bats
test/test_helper.bash
test/version-file-read.bats
test/version-file-write.bats
test/version-file.bats
test/version-name.bats
test/version-origin.bats
test/version.bats
test/versions.bats
test/whence.bats
test/which.bats
When we started to support reading `.ruby-version` files, we made a
commitment to not support fuzzy version matching. Treating "ruby-2.1.5"
as "2.1.5" is a sort of fuzzy matching, so we put in place a warning
telling you to remove the extraneous "ruby-" prefix popularly used by
other Ruby version managers to denote MRI. (Their logic is that MRI is
"ruby" and other rubies are not "ruby", apparently.)
However, people are often not able to remove the prefix in their
projects because they want to support other coworkers and tools that
sadly still require the prefix, like RubyMine.
So to restore sanity for a big portion of our users, the warning is gone.
Since communal-gems is maintainer-approved, thought it would be useful to include the directory it uses in the ignore list.
(This also helps me, since I install rbenv as submodule and without this entry, the submodule is perpetually marked dirty.)
In the event that `eval "$(rbenv init -)"` is called from a function named
rbenv (which I do to get rbenv to load lazily in my shell), evaluating the
phrase `rbenv rehash` will cause the outer function to run again (causing an
infinite loop).
This change makes it clear you want the command named rbenv and not a function
which may exist in the environment.
As it seems, JRuby 1.7 complains on stderr every time you invoke `system`:
warning: executable? does not in this environment and will return a dummy value
It doesn't seem to complain when backtics are used. It's safe to use
backticks here because `rbenv rehash` doesn't output anything on stdout,
and the exit status of the command is irrelevant.
This bakes in the functionality of rbenv-gem-rehash plugin.
The Rubygems hook is improved:
- It will not rehash for gems installed in locations that rbenv otherwise
doesn't search for binstubs; for instance in case of
`bundle --path vendor/bundle`.
- It rescues exceptions and makes them non-lethal by warning on stderr.
It doesn't need to be a bash array and we don't need a separate index of
shims registered. Simply keep everything in a space-separated string and
use that as an index as well.
This assumes that executable names *never* have spaces in them.
On my system that has 25 versions under rbenv, this speeds up rehash
almost 3-fold:
- before: 391 ms
- after: 134 ms
This is achieved by removing duplicate names of executables before
registering them as shims. Since most Rubies will share a lot of the
same executable names ("ruby", "rake", "bundle", ...), this is a
considerable reduction in number of shims registered.
Too many of our users have a shell initialization set up that
inadvertently duplicates some or most of the entries in their PATH,
bringing the system paths again in front of rbenv's shims. If this was a
nested shell (a typical scenario when starting up tmux), `rbenv init`
would get eval'd again but this time, shims won't get added to the front
of the PATH and would only stay and the end of the path, effectively
rendering them useless.
I tried to argue that this is a user problem rather than rbenv's, but I
can't fix everybody shell init when they report bugs. Instead, let's
revert to simpler times in rbenv where we just roll along with the
duplication and don't ask any questions.
This reverts commit 03fa148e81.
Fixes#369
Delegate to `rbenv-shims` instead of `rbenv shims` and therefore skip
going through the main `rbenv` executable again that would set up a lot
of the environment that was already set.
This is the remaining part of
c69d9a1128.
commit c69d9a1128
Author: Mislav Marohnić <mislav.marohnic@gmail.com>
Date: Mon Oct 13 12:39:47 2014 +0200
Isolate rbenv-which tests from any `.ruby-version` file on the system
Having a `.ruby-version` file in any of the parent directories of the
local clone of rbenv could cause the test suite to fail because it
wasn't expecting a local version to be set.
Having a `.ruby-version` file in any of the parent directories of the
local clone of rbenv could cause the test suite to fail because it
wasn't expecting a local version to be set.
Fixes#533
Running any shim (and thus `rbenv-exec`) would always execute
`rbenv-version-name` twice: once in `rbenv-exec` and another time in
`rbenv-which`, even though RBENV_VERSION variable would have already
been populated at this point.
Now RBENV_VERSION is respected within `rbenv-which`.
The previous Makefile only worked on OS X. The dynamically generated
Makefile (from `Makefile.in`) should now work on multiple platforms
(tested on OS X and Ubuntu).
The `shobj-conf` script imported from bash seems to not support the
latest OS X. This makes sure that `SHOBJ_LDFLAG=-dynamiclib` is output
for Darwin10+ (latest version is Darwin 13.0).
Given the `-o <HOST-OS>` parameter, the script generates environment
variables with information how to compile dynamically loadable libraries
for that system.
Imported from bash-3.2.48
It's slow and not necessary since we expect `$0` to already be expanded.
In tests this change forces us to deal with some relative paths, but
it's not a big deal. The `rbenv init -` output in the most common case
will be the same as before:
source '/home/myuser/.rbenv/libexec/../completions/rbenv.bash'
With `realpath` extension, hooks tests on OS X will output
`/private/tmp` instead of `/tmp` because the latter is an actual symlink
to the former.
Avoid this mistmach in output assertions by expanding BATS_TMPDIR if
`realpath` extension is compiled.
On systems that support both C compiling and dynamic loading, we can
speed up `realpath()` (where most time in rbenv is spent) by replacing
it with a dynamically loaded bash builtin.
When `make -C src` is called in the project's root,
`libexec/rbenv-realpath.dylib` will be created. If it exists, rbenv will
attempt to load it as a builtin command. If it fails, execution will
fall back to the old `realpath()` shell function.
With e.g. /usr/local/bin/.python-version owned by some user, `pyenv
local foo` would fail, if the user has no permissions for
`/usr/local/bin`, but only the `.python-version` file.
When created on Windows, .rbenv-version or .ruby-version files may have CR characters that will prevent rbenv from correctly parsing the Ruby version. Discard those characters when reading the file.
finding_local_version_file is extremely slow, when working directory is under the UNC path.
Because //host/.rbenv-version and //.rbenv-version do not exist, but testing them is so slow.
It's the reason to make a serious delay of the response, when the Ruby runs with a current working directory under the UNC path under Cygwin environment.
A response of before applying this patch.
//somehost/somedir $ time ruby -e "exit"
real 0m13.922s
user 0m0.168s
sys 0m0.287s
A response of after applying this patch.
//somehost/somedir $ time ruby -e "exit"
real 0m0.721s
user 0m0.153s
sys 0m0.319s
It seems that "comm" header can't be relied on cross-platform, but that
"ucomm" is more portable. I have no idea whether it's the right value to
use here, but it seems to be doing the job.
Also strip trailing whitespace because OpenBSD 5.4 `ps` output is padded
with spaces for some reason.
Fixes#489
On other systems, we expected to find system Ruby in `/usr/bin`, but in
OpenBSD 5.4 it will be found in `/usr/local/bin`.
This replaces the limited USRBIN_ALT hack with a more generic
`path_without` function that will ensure that the given executable is
not present in the resulting PATH even if it's found in multiple
system paths.
The error was "bash: no such file or directory" and it was due to bash
being located in `/usr/local/bin` on OpenBSD 5.4 instead of `/bin` like
on other systems.
Fixed by keeping `/usr/local/bin` in PATH during the test run.
In Travis CI environment, Bats thinks it's outputting to an interactive
terminal, so it switches to "pretty" format and ANSI escape codes which
don't look well in the final output.
Fish user config file `~/.config/fish/config.fish` loads for every
instance of fish shell, not just interactive ones. Since it's
unnecessary and dangerous to eval `rbenv init -` output in
non-interactive shells, wrap the invocation in a conditional that checks
if the current shell is interactive.
Fixes#501
It was supposed to fix shelling out to Ruby but it in fact broke another
kind of shelling out to Ruby: invoking the `ruby` binary directly with
the `-S` flag.
Fixes#480
This reverts commit db143bb654.
It doesn't exist as a builtin, and it doesn't seem there is a way to
detect support for a shell builtin that is portable. So, just detect
fish and don't the rehash command at all.
Fixes#478
`$SHELL` variable is a terrible way of detecting the current shell
because it's not even supposed to reflect the current shell; it's meant
for keeping the value of the default shell for programs to start.
If an explicit `<shell>` argument wasn't passed to `rbenv init`, it
tries to detect the shell by getting the name of its parent process. If
this fails, it falls back on the value of `$SHELL` as before.
Furthermore, `rbenv init` will set the RBENV_SHELL variable in the
current shell to the value of the detected shell so that `sh-shell` and
`sh-rehash` commands don't have to repeat the detection.
Provide an `rbenv install` example and explanation lower down, so that
both folk that are following git install and Homebrew install will
finish at the same section and learn how to use ruby-build.
Also remove step 6 of manual install process: `rbenv rehash`. It's
unnecessary at that point, even if they already did `rbenv install`
(which rehashes automatically).
Fixes#455, closes#456
Don't suggest that they add to their `.profile` anymore because:
1. They would have to restart the desktop session for their change to be
reflected, or source the file manually;
2. An error in `.profile` may prevent logging in;
3. The `rbenv()` shell function and shell completions won't be available
in Terminal since it doesn't start bash in login mode by default.
Therefore, suggest that they use `.bashrc` instead. This will be
immediately reflected in a new Terminal tab. If bash is started in login
mode somehow, the default `.profile` is set up to source `.bashrc` anyway.
Also, don't suggest restarting the shell environment with
`exec $SHELL -l`, since we don't know what was the original mode that
their shell was started in. (OS X Terminal.app will be login mode,
Ubuntu Terminal has non-login mode by default.) Mode can be checked with:
* bash: `shopt -q login_shell`
* zsh: `[[ $options[login] = "on" ]]`
But since this is gnarly, let's just avoid it altogether and go the
easy route.
Closes#305, fixes#373, reverts #286
If `rbenv init -` outputs `.` in place of `source` and that gets eval'd
by the desktop manager via `~/.profile`, it chokes and prevents the user
from logging in.
Fixes#457
ksh syntax becomes:
function rbenv {
typeset command
`typeset` only declares a local variable if there's an explicit
`function` declaration; otherwise the variable leaks.
Other shells use this syntax:
rbenv() {
local command
This is for dash compatibility, which supports neither `function` nor
`typeset`.
references #205, fixes#408
Enables shelling out from a ruby process started with rbenv to a ruby
process with a different RBENV_VERSION. Fixes#121
This removes the workaround created for #15 and solves `ruby -S` support
by setting RUBYPATH. PATH is never changed.
To illustrate how RUBYPATH changes in various configurations:
PATH=~/bin:~/.rbenv/shims:/usr/bin:/bin
RBENV_VERSION=1.8 ruby -S rake
#=> executes ~/.rbenv/versions/1.8/bin/rake
#=> RUBYPATH=~/bin:~/.rbenv/versions/1.8/bin:/usr/bin:/bin
RBENV_VERSION=2.0 ruby -S rake
#=> executes ~/.rbenv/versions/2.0/bin/rake
#=> RUBYPATH=~/bin:~/.rbenv/versions/2.0/bin:/usr/bin:/bin
RBENV_VERSION=system ruby -S rake
#=> executes /usr/bin/rake
#=> RUBYPATH=~/bin:/rbenv_shims_were_here:/usr/bin:/bin
RBENV_VERSION=1.8 ruby -S rake
#=> executes ~/.rbenv/versions/1.8/bin/rake
#=> RUBYPATH=~/bin:~/.rbenv/versions/1.8/bin:/usr/bin:/bin
readlink comes from GNU coreutils. On systems without it, rbenv used to
spin out of control when it didn't have readlink or greadlink available
because it would re-exec the frontend script over and over instead of the
worker script in libexec.
Fixes#389
This changes the zsh completion to omit the final, incomplete command
line argument when invoking rbenv completions, making it consistent with
the bash completion. Since no built-in completion cares about the
argument list, this inconsistency only affected plugins.
In systems that use the MAWK interpreter (the default AWK installed with
Ubuntu), the output of `rbenv help <command>` would have no line breaks.
The issue is fixed by changing `gsub` to `sub` in the snippet of awk
commands that are used to extract documentation comments.
I suspect the bug is something to do with the way the '^' and '$'
characters are interpreted by different AWK interpreters (per-line vs
per-string anchors).
If I understand correctly, the purpose of trim() is to remove all line
breaks from the start and end of each sections of a command's
documentation, in which case `sub` should serve the same purpose.
A command doesn't have to specify Usage docs if it doesn't accept any
arguments. The default usage for a command will be printed as:
Usage: rbenv ${command}
System ruby is already on PATH (that's the definition of system ruby) and by
duplicating its path by putting it in front, we can break the user's
environment.
Fixes#275
Docs are comprised from "Usage", "Summary" and "Help" sections, where
"Help" can span multiple commented lines. If it is missing, "Summary" is
shown in its place.
References #204, references #206
Gets rid of `doc/README.mdtoc` and its build script. Since GitHub.com
renders anchors for each heading, all we have to do is put a simple
table of contents into `README.md` itself, and everything will get
linked up nicely.
Pros of this approach:
* We don't have to point out to people not to edit `README.md` anymore
* We don't have to run the build script each time README gets edited
Cons of this change:
* The "chapter" numbers are lost. They were silly anyway.
`doc/mdtoc` renders a Markdown table of contents for a Markdown file.
`doc/filter-toc` filters that down to only headings after ToC.
This script can be used to easily insert ToC into the current document
when editing `README.md` with, e.g., Vim:
:read !doc/filter-toc %
`rbenv-versions` tries to read the current version to display a marker
next to it, but if that fails the whole script aborts.
This change makes it so that the failures from `rbenv-version-name` are
tolerated. It also makes the `--bare` mode never call it in the first
place, because it doesn't need to display a marker.
Added specific message for ksh in identifying the proper shell
initialization file.
Changed rbenv functiond definition to be more portable.
Shell functions should be defined by using the function command or
using the parenthesis grammar, but using both is not portable:
rbenv() {... -or-
function rbenv { ...
$OLDPWD is a standard shell variable that contains the previous working
directory as set by the "cd" command. No need to save $PWD to some
custom variable.
(We could also have used "cd -" but it prints out $OLDPWD too.)
A trap on the special signal EXIT is executed before the shell
terminates. EXIT actually covers SIGINT and SIGTERM as well, and
we don't need any extra traps for them.
See bash(1) and "help trap" in bash.
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`).
* [ ] 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)
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,17 @@ 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 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,14 +197,15 @@ 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>
pyenv install -l|--list
-l/--list List all available versions
-f/--force Install even if the version appears to be installed already
-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:
@@ -202,6 +215,18 @@ 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)
## `pyenv uninstall`
@@ -254,6 +279,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`
@@ -264,23 +291,82 @@ 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:
[](https://gitter.im/yyuu/pyenv?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
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.
This project was forked from [rbenv](https://github.com/sstephenson/rbenv) and
[ruby-build](https://github.com/sstephenson/ruby-build), and modified for Python.
This project was forked from [rbenv](https://github.com/rbenv/rbenv) and
[ruby-build](https://github.com/rbenv/ruby-build), and modified for Python.
@@ -65,7 +69,6 @@ executables injected into your `PATH`, determines which Python version
has been specified by your application, and passes your commands along
to the correct Python installation.
### Understanding PATH
When you run a command like `python` or `pip`, your operating system
@@ -81,13 +84,12 @@ precedence over another one at the end. In this example, the
`/usr/local/bin` directory will be searched first, then `/usr/bin`,
then `/bin`.
### Understanding Shims
pyenv works by inserting a directory of _shims_ at the front of your
`PATH`:
~/.pyenv/shims:/usr/local/bin:/usr/bin:/bin
$(pyenv root)/shims:/usr/local/bin:/usr/bin:/bin
Through a process called _rehashing_, pyenv maintains shims in that
directory to match every Python command across every installed version
@@ -102,30 +104,41 @@ operating system will do the following:
* Run the shim named `pip`, which in turn passes the command along to
pyenv
### 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:
1. The `PYENV_VERSION` environment variable (if specified). You can use
the [`pyenv shell`](#pyenv-shell) command to set this environment
the [`pyenv shell`](https://github.com/pyenv/pyenv/blob/master/COMMANDS.md#pyenv-shell) command to set this environment
variable in your current shell session.
2. The application-specific `.python-version` file in the current
directory (if present). You can modify the current directory's
`.python-version` file with the [`pyenv local`](#pyenv-local)
`.python-version` file with the [`pyenv local`](https://github.com/pyenv/pyenv/blob/master/COMMANDS.md#pyenv-local)
command.
3. The first `.python-version` file found (if any) by searching each parent
directory, until reaching the root of your filesystem.
4. The global `~/.pyenv/version` file. You can modify this file using
the [`pyenv global`](#pyenv-global) command. If the global version
4. The global `$(pyenv root)/version` file. You can modify this file using
the [`pyenv global`](https://github.com/pyenv/pyenv/blob/master/COMMANDS.md#pyenv-global) 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
`PATH`.)
**NOTE:** 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 `tox`. For example, to set
your path to first use your `system` 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
`PATH`, one would first `pyenv install` the missing versions, then set `pyenv
global system 3.3.6 3.2 2.5`. At this point, one should be able to find the full
executable path to each of these using `pyenv which`, e.g. `pyenv which python2.5`
(should display `$(pyenv root)/versions/2.5/bin/python2.5`), or `pyenv which
python3.4` (should display path to system Python3). You can also specify multiple
versions in a `.python-version` file, separated by newlines.
Lines starting with a `#` are ignored.
### Locating the Python Installation
@@ -134,16 +147,22 @@ specified, it passes the command along to the corresponding Python
installation.
Each Python version is installed into its own directory under
`~/.pyenv/versions`.
`$(pyenv root)/versions`.
For example, you might have these versions installed:
*`~/.pyenv/versions/2.7.6/`
*`~/.pyenv/versions/3.3.3/`
*`~/.pyenv/versions/pypy-2.2.1/`
*`$(pyenv root)/versions/2.7.8/`
*`$(pyenv root)/versions/3.4.2/`
*`$(pyenv root)/versions/pypy-2.4.0/`
As far as pyenv is concerned, version names are simply the directories in
`~/.pyenv/versions`.
As far as Pyenv is concerned, version names are simply directories under
`$(pyenv root)/versions`.
### Managing Virtual Environments
There is a pyenv plugin named [pyenv-virtualenv](https://github.com/pyenv/pyenv-virtualenv) which comes with various features to help pyenv users to manage virtual environments created by virtualenv or Anaconda.
Because the `activate` script of those virtual environments are relying on mutating `$PATH` 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.
----
@@ -151,145 +170,390 @@ As far as pyenv is concerned, version names are simply the directories in
## Installation
If you're on Mac OS X, consider [installing with Homebrew](#homebrew-on-mac-os-x).
### Prerequisites
For pyenv to install python correctly you should [**install the Python build dependencies**](https://github.com/pyenv/pyenv/wiki#suggested-build-environment).
### Homebrew in macOS
1. Consider installing with [Homebrew](https://brew.sh):
```sh
brew update
brew install pyenv
```
2. Then follow the rest of the post-installation steps under [Basic GitHub Checkout](https://github.com/pyenv/pyenv#basic-github-checkout), starting with #2 ("Configure your shell's environment for Pyenv").
3. OPTIONAL. To fix `brew doctor`'s warning _""config" scripts exist outside your system or Homebrew directories"_
If you're going to build Homebrew formulae from source that link against `libpython`
like Tkinter or NumPy
_(This is only generally the case if you are a developer of such a formula,
or if you have an EOL version of MacOS for which prebuilt bottles are no longer available
and are using such a formula)._
To avoid them accidentally linking against a Pyenv-provided Python,
add the following line into your interactive shell's configuration:
* Bash/Zsh:
~~~bash
alias brew='env PATH="${PATH//$(pyenv root)\/shims:/}" brew'
~~~
* Fish:
~~~fish
alias brew="env PATH=(string replace (pyenv root)/shims '' \"\$PATH\") brew"
~~~
### Windows
Pyenv does not officially support Windows and does not work in Windows outside
the Windows Subsystem for Linux.
Moreover, even there, the Pythons it installs are not native Windows versions
but rather Linux versions run through a compatibility layer --
so you won't get Windows-specific functionality.
If you're in Windows, we recommend using @kirankotari's [`pyenv-win`](https://github.com/pyenv-win/pyenv-win) fork --
which does install native Windows Python versions.
### The automatic installer
### Automatic installer
Visit my other project:
https://github.com/yyuu/pyenv-installer
Visit our other project:
https://github.com/pyenv/pyenv-installer
### Basic GitHub Checkout
This will get you going with the latest version of pyenv and make it
This will get you going with the latest version of Pyenv and make it
easy to fork and contribute any changes back upstream.
1. **Check out pyenv where you want it installed.**
A good place to choose is `$HOME/.pyenv` (but you can install it somewhere else).
1. **Check out Pyenv where you want it installed.**
A good place to choose is `$HOME/.pyenv` (but you can install it somewhere else):
set -U fish_user_paths $PYENV_ROOT/bin $fish_user_paths
~~~
And add this to `~/.config/fish/config.fish`:
~~~ fish
status is-login; and pyenv init --path | source
status is-interactive; and pyenv init - | source
~~~
If Fish is not your login shell, also follow the Bash/Zsh instructions to add to `~/.profile`.
**Proxy note**: If you use a proxy, export `http_proxy` and `https_proxy`, too.
4. **Restart your login session for the changes to profile files to take effect.**
E.g. if you're in a GUI session, you need to fully log out and log back in.
In MacOS, restarting terminal windows is enough (because MacOS runs shells
in them as login shells by default).
5. [**Install Python build dependencies**](https://github.com/pyenv/pyenv/wiki#suggested-build-environment) before attempting to install a new Python version.
6. **Install Python versions into `$(pyenv root)/versions`.**
For example, to download and install Python 2.7.8, run:
```sh
pyenv install 2.7.8
```
**NOTE:** If you need to pass a `configure` option to a build, please use the
```CONFIGURE_OPTS``` environment variable.
**NOTE:** If you want to use proxy to download, please set the `http_proxy` and `https_proxy`
environment variables.
**NOTE:** If you are having trouble installing a Python version,
If you've installed pyenv using the instructions above, you can
upgrade your installation at any time using git.
If you've installed Pyenv using Homebrew, upgrade using:
```sh
brew upgrade pyenv
```
If you've installed Pyenv using the instructions above, you can
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
### Homebrew on Mac OS X
The simplicity of pyenv makes it easy to temporarily disable it, or
uninstall from the system.
You can also install pyenv using the [Homebrew](http://brew.sh)
package manager for Mac OS X.
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.
$ brew update
$ brew install pyenv
`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, remove _all_ configuration lines for it
from your shell startup configuration, and then remove
its root directory. This will **delete all Python versions** that were
installed under `` $(pyenv root)/versions/ `` directory:
```sh
rm -rf $(pyenv root)
```
To upgrade pyenv in the future, just use `upgrade` instead of `install`.
If you've installed Pyenv using a package manager, as a final step,
perform the Pyenv package removal. For instance, for Homebrew:
After installation, you'll still need to add `eval "$(pyenv init -)"` to your
profile (as stated in the caveats). You'll only ever have to do this
once.
```
brew uninstall pyenv
```
### Neckbeard Configuration
### 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:
extra commands into your shell. Coming from RVM, some of you might be
opposed to this idea.
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`.
Also see the [Environment variables](#environment-variables) section
for the environment variables that control Pyenv's behavior.
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.
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.
* `eval "$(pyenv init --path)"`:
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
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.
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 root)/shims` to your `$PATH`.
`eval "$(pyenv init --path)"` is supposed to be run in your session's login
shell startup script -- so that all processes in the session get access to
Pyenv's functionality and it only runs once,
avoiding breaking `PATH` in nested shells
(e.g. shells started from editors/IDEs).
In Linux, GUI managers typically act as a `sh` login shell, running
`/etc/profile` and `~/.profile` at their startup. MacOS' GUI doesn't do that,
so its terminal emulator apps run their shells as login shells by default
to compensate.
To see exactly what happens under the hood for yourself, run `pyenv init -`.
* `eval "$(pyenv init -)"`:
1. **Installs autocompletion.** This is entirely optional but pretty
useful. Sourcing `$(pyenv root)/completions/pyenv.bash` will set that
up. There is also a `$(pyenv root)/completions/pyenv.zsh` for Zsh
users.
2. **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.
3. **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, making
commands like `pyenv shell` possible. 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.
`eval "$(pyenv init -)"` is supposed to run at any interactive shell's
startup (including nested shells) so that you get completion and
convenience shell functions.
To see exactly what happens under the hood for yourself, run `pyenv init -`
or `pyenv init --path`.
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`, which you can manually execute or symlink
as required.
### Uninstalling Python Versions
As time goes on, you will accumulate Python versions in your
`~/.pyenv/versions` directory.
`$(pyenv root)/versions` directory.
To remove old Python versions, `pyenv uninstall` command to automate
the removal process.
Alternatively, simply `rm -rf` the directory of the version you want
to remove. You can find the directory of a particular Python version
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`.
@@ -303,43 +567,43 @@ See [COMMANDS.md](COMMANDS.md).
----
## Environment variables
You can affect how pyenv operates with the following settings:
name | default | description
-----|---------|------------
`PYENV_VERSION` | | Specifies the Python version to be used.<br>Also see [`pyenv shell`](https://github.com/pyenv/pyenv/blob/master/COMMANDS.md#pyenv-shell)
`PYENV_ROOT` | `~/.pyenv` | Defines the directory under which Python versions and shims reside.<br>Also see `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
## Development
The pyenv source code is [hosted on GitHub](https://github.com/yyuu/pyenv).
It's clean, modular, and easy to understand--even if you're not a shell hacker.
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\.
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 a specific Python version
.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\.
.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:
.IP""4
.nf
$ pyenv install \-\-list
.fi
.IP""0
.P
Then install the desired versions:
.IP""4
.nf
$ 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)
.fi
.IP""0
.SS"pyenv uninstall"
Uninstall a specific Python version\.
.IP""4
.nf
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
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 provides a `pyenv install` command to compile and install
different versions of Python on UNIX-like systems.
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.
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/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)
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.
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 git://github.com/pyenv/pyenv.git
cd pyenv/plugins/python-build
./install.sh
This will install python-build into `/usr/local`. If you do not have
write permission to `/usr/local`, you will need to run `sudo
./install.sh` instead. You can install to a different prefix by
setting the `PREFIX` environment variable.
This will install python-build into `/usr/local`. If you do not have write
permission to `/usr/local`, you will need to run `sudo ./install.sh` instead.
You can install to a different prefix by setting the `PREFIX` environment
variable.
To update python-build after it has been installed, run `git pull` in
your cloned copy of the repository, then re-run the install script.
To update python-build after it has been installed, run `git pull` in your cloned
copy of the repository, then re-run the install script.
### Installing with Homebrew (for OS X users)
Mac OS X users can install python-build with the [Homebrew](http://brew.sh)
package manager. This will give you access to the `python-build` command. If you
have pyenv installed, you will also be able to use the `pyenv install` command.
*This is the recommended method of installation if you installed pyenv with
Homebrew.*
brew install pyenv
Or, if you would like to install the latest development release:
brew install --HEAD pyenv
## 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/pyenv/pyenv/wiki#suggested-build-environment)).
### Using `pyenv install` with pyenv
To install a Python version for use with pyenv, run `pyenv install` with
the exact name of the version you want to install. For example,
exact name of the version you want to install. For example,
pyenv install 2.7.4
Python versions will be installed into a directory of the same name
under `~/.pyenv/versions`.
Python versions will be installed into a directory of the same name under
`~/.pyenv/versions`.
To see a list of all available Python versions, run `pyenv install --list`.
You may also tab-complete available Python
versions if your pyenv installation is properly configured.
To see a list of all available Python versions, run `pyenv install --list`. You
may also tab-complete available Python versions if your pyenv installation is
properly configured.
### Using `python-build` standalone
If you have installed python-build as a standalone program, you can use
the `python-build` command to compile and install Python versions into
specific locations.
If you have installed python-build as a standalone program, you can use the
`python-build` command to compile and install Python versions into specific
locations.
Run the `python-build` command with the exact name of the version you
want to install and the full path where you want to install it. For
example,
Run the `python-build` command with the exact name of the version you want to
install and the full path where you want to install it. For example,
python-build 2.7.4 ~/local/python-2.7.4
To see a list of all available Python versions, run `python-build
--definitions`.
To see a list of all available Python versions, run `python-build --definitions`.
Pass the `-v` or `--verbose` flag to `python-build` as the first
argument to see what's happening under the hood.
Pass the `-v` or `--verbose` flag to `python-build` as the first argument to see
what's happening under the hood.
### Custom definitions
Both `pyenv install` and `python-build` accept a path to a custom
definition file in place of a version name. Custom definitions let you
develop and install versions of Python that are not yet supported by
python-build.
Both `pyenv install` and `python-build` accept a path to a custom definition file
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/pyenv/pyenv/tree/master/plugins/python-build/share/python-build) as a starting point for
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.
