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
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.
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
2014-01-09 15:31:29 +09:00
560 changed files with 12041 additions and 2307 deletions
Too many issues will kill our team's development velocity, drastically.
Make sure you have checked all steps below.
### Prerequisite
* [ ] Make sure your problem is not listed in [the common build problems](https://github.com/pyenv/pyenv/wiki/Common-build-problems).
* [ ] Make sure no duplicated issue has already been reported in [the pyenv issues](https://github.com/pyenv/pyenv/issues). You should look for closed issues, too.
* [ ] Make sure you are not asking us to help solving your specific issue.
* GitHub issues is opened mainly for development purposes. If you want to ask someone to help solving your problem, go to some community site like [Gitter](https://gitter.im/yyuu/pyenv), [StackOverflow](https://stackoverflow.com/questions/tagged/pyenv), etc.
* [ ] Make sure your problem is not derived from packaging (e.g. [Homebrew](https://brew.sh)).
* Please refer to the package documentation for the installation issues, etc.
* [ ] Make sure your problem is not derived from plugins.
* This repository is maintaining `pyenv` and the default `python-build` plugin only. Please refrain from reporting issues of other plugins here.
### Description
- [ ] Platform information (e.g. Ubuntu Linux 16.04):
- [ ] OS architecture (e.g. amd64):
- [ ] pyenv version:
- [ ] Python version:
- [ ] C Compiler information (e.g. gcc 7.3):
- [ ] Please attach verbose build log as gist
* You can turn on verbose debug logging using by setting `PYENV_DEBUG=1`, e.g. `env PYENV_DEBUG=1 pyenv install -v 3.6.4`
* [ ] Please 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)
- https://github.com/pyenv/pyenv/issues/XXXX
### Description
- [ ] Here are some details about my PR
### Tests
- [ ] My PR adds the following unit tests (if any)
[](https://gitter.im/yyuu/pyenv?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
@@ -65,7 +67,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 +82,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,31 +102,30 @@ 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 mulitple
**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
@@ -134,8 +133,9 @@ 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).
(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
@@ -144,16 +144,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.8/`
*`~/.pyenv/versions/3.4.2/`
*`~/.pyenv/versions/pypy-2.4.0/`
*`$(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`.
`$(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.
----
@@ -161,13 +167,14 @@ As far as pyenv is concerned, version names are simply the directories in
## Installation
If you're on MacOS X, consider [installing with Homebrew](#homebrew-on-mac-os-x).
If you're on macOS, consider [installing with Homebrew](#homebrew-on-macos).
If you're on Windows, consider using @kirankotari's [`pyenv-win`](https://github.com/pyenv-win/pyenv-win) fork. (`pyenv` does not work on windows outside the Windows Subsystem for Linux)
### The automatic installer
Visit my other project:
https://github.com/yyuu/pyenv-installer
https://github.com/pyenv/pyenv-installer
### Basic GitHub Checkout
@@ -178,60 +185,61 @@ 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).
@@ -241,35 +249,59 @@ 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:
$ cd ~/.pyenv
$ git fetch
$ git tag
v0.1.0
$ git checkout v0.1.0
```sh
$ cd $(pyenv root)
$ git fetch
$ git tag
v0.1.0
$ 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` 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.
`pyenv` will still be accessible on the command line, but your Python
apps won't be affected by version switching.
2. To completely **uninstall** pyenv, perform step (1) and then remove
its root directory. This will **delete all Python versions** that were
installed under `` $(pyenv root)/versions/ `` directory:
```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:
brew uninstall pyenv
### Homebrew on macOS
You can also install pyenv using the [Homebrew](https://brew.sh)
package manager for macOS.
$ brew update
$ brew install pyenv
To upgrade pyenv in the future, just use `upgrade` instead of `install`.
To upgrade pyenv in the future, use `upgrade` instead of `install`.
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.
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").
### Neckbeard Configuration
### Advanced Configuration
Skip this section unless you must know what every line in your shell
profile is doing.
@@ -280,11 +312,11 @@ 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/shims` to your `$PATH`.
`$(pyenv root)/shims` to your `$PATH`.
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
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
@@ -304,7 +336,7 @@ 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/versions` directory.
`$(pyenv root)/versions` directory.
To remove old Python versions, `pyenv uninstall` command to automate
the removal process.
@@ -324,43 +356,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 `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
## 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.
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.
### 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-3.3.1" "https://www.python.org/ftp/python/3.3.1/Python-3.3.1.tgz#671dc3632f311e63c6733703aa0a1ad90c99277ddc8299d39e487718a50319bd" ldflags_dirs standard verify_py33 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.
