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 `pyenv foo bar --flag`, then
this allows the last `--flag` argument to be properly completed.
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.
```
/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)
```
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.
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
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
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.
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.
The `diff --git a/` indicates that the patch is generated from `git diff`
and it should be applied with `patch -p1`. Because the patches bundled
with python-build have already re-formated for `patch -p0`, this is not
the desired behaviour.
Just removing `diff --git` from patches will force python-build to apply
those patches with `patch -p0`.
Because the variables specified via command-line arguments for the
`./configure` will be favored than one in environment variables,
setting those variables in `PACKAGE_CONFIGURE_OPTS_ARRAY` will hide
existing environment variables.
To avoid the problem, stop using `package_option()` to setup those
variables.
Also added `help` output for `pyenv {,un}install`, since those sections didn’t exist before.
They should probably be revised at some point. In the meantime, I think something is better than nothing (in this case).
The `pwd` may return relative path if the `$PWD` is badly declared
in bash/zsh (e.g. `PWD="." bash`). To avoid the infinite loop in
`find_local_version_file()`, stop finding the version file if the
target paths are same consecutively.
There is filterdiff(1) available to transform strip level of a patch if
optional level is required.
```
git diff HEAD^ | filterdiff --strip=1 | pyenv install -p 3.3.3
```
Updated README.md contents so that installation instructions cover
not only the common case for installation directory, i.e. `~/.pyenv`
but any other at the user's choice.
* verify checksum of downloaded archives.
* add PYTHON_BUILD_MIRROR_URL to use mirror site.
But we don't have CloudFront setup as of now :-(
* rbenv 0.4.x style help messages
* python-build: Add IronPython versions (setuptools and pip will work); ironpython-2.7.4, ironpython-dev
* python-build: Add new Jython beta release; jython-2.7-beta2
* python-build: Update default setuptools version (3.4.1 -> 3.6)
* python-build: Update default pip version (1.5.4 -> 1.5.5)
* python-build: Update GNU Readline (6.2 -> 6.3)
* python-build: Import recent changes from ruby-build v20140420
#### 0.4.0-20140404
* pyenv: Reads only the first word from version file. This is as same behavior as rbenv.
* python-build: Fix build of Tkinter with Tcl/Tk 8.6 (#131)
* python-build: Fix build problem with Readline 6.3 (#126, #131, #149, #152)
* python-build: Do not exit with errors even if some of modules are absent (#131)
* python-build: MacOSX was misspelled as MaxOSX in `anaconda_architecture` (#136)
* python-build: Use default `cc` as the C Compiler to build CPython (#148, #150)
* python-build: Display value from `pypy_architecture` and `anaconda_architecture` on errors (pyenv/pyenv-virtualenv#18)
* python-build: Remove old development version; 2.6-dev
* python-build: Update default setuptools version (3.3 -> 3.4.1)
#### 0.4.0-20140317
* python-build: Add new CPython releases; 3.4.0 (#133)
* python-build: Add new Anaconda releases; anaconda-1.9.0, anaconda-1.9.1
* python-build: Add new Miniconda releases; miniconda-3.0.4, miniconda-3.0.5, miniconda3-3.0.4, miniconda3-3.0.5
* python-build: Update default setuptools version (3.1 -> 3.3)
#### 0.4.0-20140311
* python-build: Add new CPython releases; 3.3.5 (#127)
* python-build: Add new CPython release candidates; 3.4.0rc1, 3.4.0rc2, 3.4.0rc3
* python-build: Update default setuptools version (2.2 -> 3.1)
* python-build: Update default pip version (1.5.2 -> 1.5.4)
* python-build: Import recent changes from ruby-build v20140225
#### 0.4.0-20140211
* python-build: Add new CPython release candidates; 3.3.4, 3.4.0b3
* python-build: Add [Anaconda](https://store.continuum.io/cshop/anaconda/) and [Miniconda](http://repo.continuum.io/miniconda/) binary distributions
* python-build: Display error if the wget does not support Server Name Indication (SNI) to avoid SSL verification error when downloading from https://pypi.python.org. (#60)
* python-build: Update default setuptools version (2.1 -> 2.2)
* python-build: Update default pip version (1.5.1 -> 1.5.2)
* python-build: Import recent changes from ruby-build v20140204
#### 0.4.0-20140123
* pyenv: Always append the directory at the top of the `$PATH` to return proper value for `sys.executable` (#98)
* pyenv: Unset `GREP_OPTIONS` to avoid issues of conflicting options (#101)
* python-build: Install `pip` with using `ensurepip` if available
* python-build: Add support for framework installation (`--enable-framework`) of CPython (#55, #99)
* python-build: Import recent changes from ruby-build v20140110.1
* python-build: Import `bats` tests from ruby-build v20140110.1
#### 0.4.0-20140110.1
* python-build: Fix build error of CPython 2.x on the platform where the `gcc` is llvm-gcc.
#### 0.4.0-20140110
* pyenv: Reliably detect parent shell in `pyenv init` (#93)
* pyenv: Import recent changes from rbenv 0.4.0
* pyenv: Import `bats` tests from rbenv 0.4.0
* python-build: Add new CPython releases candidates; 3.4.0b2
# Seamlessly manage your app’s Ruby environment with rbenv.
# Simple Python Version Management: pyenv
[](https://gitter.im/yyuu/pyenv?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
rbenv is a version manager tool for the Ruby programming language on Unix-like systems. It is useful for switching between multiple Ruby versions on the same machine and for ensuring that each project you are working on always runs on the correct Ruby version.
## How It Works
After rbenv injects itself into your PATH at installation time, any invocation of `ruby`, `gem`, `bundler`, or other Ruby-related executable will first activate rbenv. Then, rbenv scans the current project directory for a file named `.ruby-version`. If found, that file determines the version of Ruby that should be used within that directory. Finally, rbenv looks up that Ruby version among those installed under `~/.rbenv/versions/`.
At a high level, pyenv intercepts Python commands using shim
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.
You can choose the Ruby version for your project with, for example:
```sh
cd myproject
# choose Ruby version 3.1.2:
rbenv local 3.1.2
```
### Understanding PATH
Doing so will create or update the `.ruby-version` file in the current directory with the version that you've chosen. A different project of yours that is another directory might be using a different version of Ruby altogether—rbenv will seamlessly transition from one Ruby version to another when you switch projects.
When you run a command like `python` or `pip`, 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 `PATH`, with each directory in the list separated by a colon:
Finally, almost every aspect of rbenv's mechanism is [customizable via plugins][plugins] written in bash.
/usr/local/bin:/usr/bin:/bin
Directories in `PATH` 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
`/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 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
of Python—`python`, `pip`, and so on.
Shims are lightweight executables that simply pass your command along
to pyenv. So with pyenv installed, when you run, say, `pip`, your
operating system will do the following:
* Search your `PATH` for an executable file named `pip`
* Find the pyenv shim named `pip` at the beginning of your `PATH`
* 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`](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`](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 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 or any whitespace.
### 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.
Each Python version is installed into its own directory under
`$(pyenv root)/versions`.
For example, you might have these versions installed:
*`$(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 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.
----
The simplicity of rbenv has its benefits, but also some downsides. See the [comparison of version managers][alternatives] for more details and some alternatives.
## Installation
On systems with Homebrew package manager, the “Using Package Managers” method is recommended. On other systems, “Basic Git Checkout” might be the easiest way of ensuring that you are always installing the latest version of rbenv.
If you're on Mac OS X, consider [installing with Homebrew](#homebrew-on-mac-os-x).
### Using Package Managers
1. Install rbenv using one of the following approaches.
### The automatic installer
#### Homebrew
On macOS or Linux, we recommend installing rbenv with [Homebrew](https://brew.sh).
```sh
brew install rbenv
```
#### Debian, Ubuntu, and their derivatives
> [!CAUTION]
> The version of rbenv that is packaged and maintained in official
Debian and Ubuntu repositories is _out of date_. To install the latest
version, it is recommended to [install rbenv using git](#basic-git-checkout).
```sh
sudo apt install rbenv
```
#### Arch Linux and its derivatives
Archlinux has an [AUR Package](https://aur.archlinux.org/packages/rbenv/) for
rbenv and you can install it from the AUR using the instructions from this
**Zsh note**: Modify your `~/.zshenv` file instead of `~/.bash_profile`.
**Ubuntu and Fedora note**: Modify your `~/.bashrc` file instead of `~/.bash_profile`.
**Proxy note**: If you use a proxy, export `http_proxy` and `HTTPS_PROXY` too.
3. Close your Terminal window and open a new one so your changes take effect.
That's it! You are now ready to [install some Ruby versions](#installing-ruby-versions).
### Basic Git Checkout
> [!NOTE]
> For a more automated install, you can use [rbenv-installer](https://github.com/rbenv/rbenv-installer#rbenv-installer). If you do not want to execute scripts downloaded from a web URL or simply prefer a manual approach, follow the steps below.
This will get you going with the latest version of rbenv without needing a system-wide install.
1. Clone rbenv into `~/.rbenv`.
3. **Add `pyenv init` to your shell** to enable shims and autocompletion.
Please make sure `eval "$(pyenv init -)"` is placed toward the end of the shell
configuration file since it manipulates `PATH` during the initialization.
When _manually_ installing rbenv, it might be useful to note how completion scripts for various shells work. Completion scripts help with typing rbenv commands by expanding partially entered rbenv command names and option flags; typically this is invoked by pressing <kbd>Tab</kbd> key in an interactive shell.
#### Upgrading
- The **bash** completion script for rbenv ships with the project and gets [loaded by the `rbenv init` mechanism](#how-rbenv-hooks-into-your-shell).
If you've installed pyenv using the instructions above, you can
upgrade your installation at any time using git.
- The **zsh** completion script ships with the project, but needs to be added to FPATH in zsh before it can be discovered by the shell. One way to do this would be to edit `~/.zshrc`:
```sh
# assuming that rbenv was installed to `~/.rbenv`
FPATH=~/.rbenv/completions:"$FPATH"
autoload -U compinit
compinit
```
- The **fish** completion script for rbenv ships with the fish shell itself and is not maintained by the rbenv project.
### Installing Ruby versions
The `rbenv install` command does not ship with rbenv out-of-the-box, but is provided by the [ruby-build][] plugin.
Before attempting to install Ruby, **check that [your build environment](https://github.com/rbenv/ruby-build/wiki#suggested-build-environment) has the necessary tools and libraries**. Then:
To upgrade to the latest development version of pyenv, use `git pull`:
```sh
# list latest stable versions:
rbenv install -l
# list all local versions:
rbenv install -L
# install a Ruby version:
rbenv install 3.1.2
$ cd $(pyenv root)
$ git pull
```
For troubleshooting `BUILD FAILED` scenarios, check the [ruby-build Discussions section](https://github.com/rbenv/ruby-build/discussions/categories/build-failures).
> [!NOTE]
> If the `rbenv install` command wasn't found, you can install ruby-build as a plugin:
Set a Ruby version to finish installation and start using Ruby:
```sh
rbenv global 3.1.2 # set the default Ruby version for this machine
# or:
rbenv local 3.1.2 # set the Ruby version for this directory
```
Alternatively to the `rbenv install` command, you can download and compile Ruby manually as a subdirectory of `~/.rbenv/versions`. An entry in that directory can also be a symlink to a Ruby version installed elsewhere on the filesystem.
#### Installing Ruby gems
Select a Ruby version for your project using `rbenv local 3.1.2`, for example. Then, proceed to install gems as you normally would:
To upgrade to a specific release of pyenv, check out the corresponding tag:
```sh
gem install bundler
$ cd $(pyenv root)
$ git fetch
$ git tag
v0.1.0
$ git checkout v0.1.0
```
> [!NOTE]
> You _should not use sudo_ to install gems. Typically, the Ruby versions will be installed under your home directory and thus writeable by your user. If you get the “you don't have write permissions” error when installing gems, it's likely that your "system" Ruby version is still a global default. Change that with `rbenv global <version>` and try again.
### Uninstalling pyenv
Check the location where gems are being installed with `gem env`:
The simplicity of pyenv makes it easy to temporarily disable it, or
1. To **disable** pyenv managing your Python versions, simply remove the
`pyenv init` line from your shell startup configuration. This will
remove pyenv shims directory from PATH, and future invocations like
`python` will execute the system Python version, as before pyenv.
#### Uninstalling Ruby versions
`pyenv` will still be accessible on the command line, but your Python
apps won't be affected by version switching.
As time goes on, Ruby versions you install will accumulate in your
`~/.rbenv/versions` directory.
2. To completely **uninstall** pyenv, perform step (1) and then remove
its root directory. This will **delete all Python versions** that were
installed under `` $(pyenv root)/versions/ `` directory:
```sh
rm -rf $(pyenv root)
```
If you've installed pyenv using a package manager, as a final step
perform the pyenv package removal. For instance, for Homebrew:
To remove old Ruby versions, simply `rm -rf` the directory of the
version you want to remove. You can find the directory of a particular
Ruby version with the `rbenv prefix` command, e.g. `rbenv prefix
2.7.0`.
brew uninstall pyenv
### Homebrew on Mac OS X
You can also install pyenv using the [Homebrew](http://brew.sh)
package manager for Mac OS X.
$ brew update
$ brew install pyenv
To upgrade pyenv in the future, use `upgrade` instead of `install`.
Then follow the rest of the post-installation steps under [Basic GitHub Checkout](https://github.com/pyenv/pyenv#basic-github-checkout) above, starting with #3 ("Add `pyenv init` to your shell to enable shims and autocompletion").
### 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:
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`.
2. **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.
3. **Rehashes shims.** From time to time you'll need to rebuild your
shim files. Doing this on init makes sure everything is up to
date. You can always run `pyenv rehash` manually.
4. **Installs the sh dispatcher.** This bit is also optional, but allows
pyenv and plugins to change variables in your current shell, making
commands like `pyenv shell` possible. The sh dispatcher doesn't do
anything crazy like override `cd` or hack your shell prompt, but if
for some reason you need `pyenv` to be a real script rather than a
shell function, you can safely skip it.
To see exactly what happens under the hood for yourself, run `pyenv init -`.
### Uninstalling Python Versions
As time goes on, you will accumulate Python versions in your
`$(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
with the `pyenv prefix` command, e.g. `pyenv prefix 2.6.8`.
----
The [ruby-build][] plugin provides an `rbenv uninstall` command to
automate the removal process.
## Command Reference
The main rbenv commands you need to know are:
See [COMMANDS.md](COMMANDS.md).
### rbenv versions
Lists all Ruby versions known to rbenv, and shows an asterisk next to
the currently active version.
$ rbenv versions
1.8.7-p352
1.9.2-p290
* 1.9.3-p327 (set by /Users/sam/.rbenv/version)
jruby-1.7.1
rbx-1.2.4
ree-1.8.7-2011.03
### rbenv version
Displays the currently active Ruby version, along with information on
how it was set.
$ rbenv version
1.9.3-p327 (set by /Users/sam/.rbenv/version)
### rbenv local
Sets a local application-specific Ruby version by writing the version
name to a `.ruby-version` file in the current directory. This version
overrides the global version, and can be overridden itself by setting
the `RBENV_VERSION` environment variable or with the `rbenv shell`
command.
rbenv local 3.1.2
When run without a version number, `rbenv local` reports the currently
configured local version. You can also unset the local version:
rbenv local --unset
### rbenv global
Sets the global version of Ruby to be used in all shells by writing
the version name to the `~/.rbenv/version` file. This version can be
overridden by an application-specific `.ruby-version` file, or by
setting the `RBENV_VERSION` environment variable.
rbenv global 3.1.2
The special version name `system` tells rbenv to use the system Ruby
(detected by searching your `$PATH`).
When run without a version number, `rbenv global` reports the
currently configured global version.
### rbenv shell
Sets a shell-specific Ruby version by setting the `RBENV_VERSION`
environment variable in your shell. This version overrides
application-specific versions and the global version.
rbenv shell jruby-1.7.1
When run without a version number, `rbenv shell` reports the current
value of `RBENV_VERSION`. You can also unset the shell version:
rbenv shell --unset
Note that you'll need rbenv'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
`RBENV_VERSION` variable yourself:
export RBENV_VERSION=jruby-1.7.1
### rbenv rehash
Installs shims for all Ruby executables known to rbenv (`~/.rbenv/versions/*/bin/*`). Typically you do not need to run this command, as it will run automatically after installing gems.
rbenv rehash
### rbenv which
Displays the full path to the executable that rbenv will invoke when
you run the given command.
$ rbenv which irb
/Users/sam/.rbenv/versions/1.9.3-p327/bin/irb
### rbenv whence
Lists all Ruby versions that contain the specified executable name.
$ rbenv whence rackup
1.9.3-p327
jruby-1.7.1
ree-1.8.7-2011.03
----
## Environment variables
You can affect how rbenv operates with the following settings:
You can affect how pyenv operates with the following settings:
name | default | description
-----|---------|------------
`RBENV_VERSION` | | Specifies the Ruby version to be used.<br>Also see [`rbenv shell`](#rbenv-shell)
`RBENV_ROOT` | `~/.rbenv` | Defines the directory under which Ruby versions and shims reside.<br>Also see `rbenv root`
`RBENV_HOOK_PATH` | [_see wiki_][hooks] | Colon-separated list of paths searched for rbenv hooks.
`RBENV_DIR` | `$PWD` | Directory to start searching for `.ruby-version` files.
### How rbenv hooks into your shell
`rbenv init` is a helper command to hook rbenv into a shell. This helper is part of the recommended installation instructions, but optional, as an experienced user can set up the following tasks manually. The `rbenv init` command has two modes of operation:
1. `rbenv init`: made for humans, this command edits your shell initialization files on disk to add rbenv to shell startup. (Prior to rbenv 1.3.0, this mode only printed user instructions to the terminal, but did nothing else.)
2. `rbenv init -`: made for machines, this command outputs a shell script suitable to be eval'd by the user's shell.
When `rbenv init` is invoked from a bash shell, for example, it will add the following to the user's `~/.bashrc` or `~/.bash_profile`:
```sh
# Added by `rbenv init` on <DATE>
eval "$(rbenv init - --no-rehash bash)"
```
You may add this line to your shell initialization files manually if you want to avoid running `rbenv init` as part of the setup process. Here is what the eval'd script does:
0. Adds `rbenv` executable to PATH if necessary.
1. Prepends `~/.rbenv/shims` directory to PATH. This is basically the only requirement for rbenv to function properly.
2. Installs bash shell completion for rbenv commands.
3. Regenerates rbenv shims. If this step slows down your shell startup, you can invoke `rbenv init -` with the `--no-rehash` flag.
4. Installs the "sh" dispatcher. This bit is also optional, but allows rbenv and plugins to change variables in your current shell, making commands like `rbenv shell` possible.
`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 `aria2c` binary is available on PATH, pyenv use `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
### Uninstalling rbenv
The simplicity of rbenv makes it easy to temporarily disable it, or
uninstall from the system.
1. To **disable** rbenv managing your Ruby versions, simply comment or remove the `rbenv init` line from your shell startup configuration. This will remove rbenv shims directory from PATH, and future invocations like `ruby` will execute the system Ruby version, bypassing rbenv completely.
While disabled, `rbenv` will still be accessible on the command line, but your Ruby apps won't be affected by version switching.
2. To completely **uninstall** rbenv, perform step (1) and then remove the rbenv root directory. This will **delete all Ruby versions** that were installed under `` `rbenv root`/versions/ ``:
rm -rf "$(rbenv root)"
If you've installed rbenv using a package manager, as a final step
perform the rbenv package removal:
- Homebrew: `brew uninstall rbenv`
- Debian, Ubuntu, and their derivatives: `sudo apt purge rbenv`
- Archlinux and its derivatives: `sudo pacman -R rbenv`
## Development
Tests are executed using [Bats](https://github.com/bats-core/bats-core):
python-build is a [pyenv](https://github.com/pyenv/pyenv) plugin that
provides a `pyenv install` command to compile and install different versions
of Python on UNIX-like systems.
You can also use python-build without pyenv in environments where you need
precise control over Python version installation.
See the [list of releases](https://github.com/pyenv/pyenv/releases)
for changes in each version.
## Installation
### Installing as a pyenv plugin (recommended)
You need nothing to do since python-build is bundled with pyenv by
default.
### 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.
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.
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
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`.
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.
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`.
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.
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 "readline-6.3" "https://ftpmirror.gnu.org/readline/readline-6.3.tar.gz#56ba6071b9462f980c5a72ab0023893b65ba6debb4eeb475d7a563dc65cafd43" standard --if has_broken_mac_readline
if has_tar_xz_support; then
install_package "Python-2.7.13" "https://www.python.org/ftp/python/2.7.13/Python-2.7.13.tar.xz#35d543986882f78261f97787fd3e06274bfa6df29fac9b4a94f73930ff98f731" ldflags_dirs standard verify_py27 ensurepip
else
install_package "Python-2.7.13" "https://www.python.org/ftp/python/2.7.13/Python-2.7.13.tgz#a4f05a0720ce0fd92626f0278b6b433eee9a6173ddf2bced7957dfb599a5ece1" ldflags_dirs standard verify_py27 ensurepip
fi
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.