Coder Social home page Coder Social logo

pyenv-virtualenv's Introduction

Simple Python Version Management: pyenv

Join the chat at https://gitter.im/yyuu/pyenv

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 and ruby-build, and modified for Python.

Terminal output example

What pyenv does...

  • Lets you change the global Python version on a per-user basis.
  • Provides support for per-project Python versions.
  • Allows you to override the Python version with an environment variable.
  • Searches for commands from multiple versions of Python at a time. This may be helpful to test across Python versions with tox.

In contrast with pythonbrew and pythonz, pyenv does not...

  • Depend on Python itself. pyenv was made from pure shell scripts. There is no bootstrap problem of Python.
  • Need to be loaded into your shell. Instead, pyenv's shim approach works by adding a directory to your PATH.
  • Manage virtualenv. Of course, you can create virtualenv yourself, or pyenv-virtualenv to automate the process.

Table of Contents


How It Works

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.

Understanding PATH

When you run a command like python or pip, your shell (bash / zshrc / ...) 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:

/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

Understanding Python version selection

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 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 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 command. If the global version file is not present, pyenv assumes you want to use the "system" Python (see below).

A special version name "system" means to use whatever Python is found on PATH after the shims PATH entry (in other words, whatever would be run if Pyenv shims weren't on PATH). Note that Pyenv considers those installations outside its control and does not attempt to inspect or distinguish them in any way. So e.g. if you are on MacOS and have OS-bundled Python 3.8.9 and Homebrew-installed Python 3.9.12 and 3.10.2 -- for Pyenv, this is still a single "system" version, and whichever of those is first on PATH under the executable name you specified will be run.

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 instruct Pyenv to first use your system Python and Python3 (which are e.g. 2.7.9 and 3.4.2) but also have Python 3.3.6, 3.2.1, and 2.5.2 available, you first pyenv install the missing versions, then set pyenv global system 3.3.6 3.2.1 2.5.2. Then you'll be able to invoke any of those versions with an appropriate pythonX or pythonX.Y name. You can also specify multiple versions in a .python-version file by hand, separated by newlines. Lines starting with a # are ignored.

pyenv which <command> displays which real executable would be run when you invoke <command> via a shim. E.g. if you have 3.3.6, 3.2.1 and 2.5.2 installed of which 3.3.6 and 2.5.2 are selected and your system Python is 3.2.5, pyenv which python2.5 should display $(pyenv root)/versions/2.5.2/bin/python2.5, pyenv which python3 -- $(pyenv root)/versions/3.3.6/bin/python3 and pyenv which python3.2 -- path to your system Python due to the fall-through (see below).

Shims also fall through to anything further on PATH if the corresponding executable is not present in any of the selected Python installations. This allows you to use any programs installed elsewhere on the system as long as they are not shadowed by a selected Python installation.

Locating Pyenv-provided Python installations

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 directories under $(pyenv root)/versions.


Installation

Getting Pyenv

UNIX/MacOS

Homebrew in macOS
  1. Consider installing with Homebrew:

    brew update
    brew install pyenv

    If you want to install (and update to) the latest development head of Pyenv rather than the latest release, instead run:

    brew install pyenv --head
  2. Then follow the rest of the post-installation steps, starting with Set up your shell 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 Python 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 provided and you 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:

      alias brew='env PATH="${PATH//$(pyenv root)\/shims:/}" brew'
    • Fish:

      alias brew="env PATH=(string replace (pyenv root)/shims '' \"\$PATH\") brew"
Automatic installer
curl https://pyenv.run | bash

For more details 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 easy to fork and contribute any changes back upstream.

  • Check out Pyenv where you want it installed. A good place to choose is $HOME/.pyenv (but you can install it somewhere else):
    git clone https://github.com/pyenv/pyenv.git ~/.pyenv
    
  • Optionally, try to compile a dynamic Bash extension to speed up Pyenv. Don't worry if it fails; Pyenv will still work normally:
    cd ~/.pyenv && src/configure && make -C src
    

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 running in a virtual machine -- so you won't get Windows-specific functionality.

If you're in Windows, we recommend using @kirankotari's pyenv-win fork -- which does install native Windows Python versions.

Set up your shell environment for Pyenv

Upgrade note: The startup logic and instructions have been updated for simplicity in 2.3.0. The previous, more complicated configuration scheme for 2.0.0-2.2.5 still works.

  • Define environment variable PYENV_ROOT to point to the path where Pyenv will store its data. $HOME/.pyenv is the default. If you installed Pyenv via Git checkout, we recommend to set it to the same location as where you cloned it.
  • Add the pyenv executable to your PATH if it's not already there
  • run eval "$(pyenv init -)" to install pyenv into your shell as a shell function, enable shims and autocompletion
    • You may run eval "$(pyenv init --path)" instead to just enable shims, without shell integration

The below setup should work for the vast majority of users for common use cases. See Advanced configuration for details and more configuration options.

  • For bash:

    Stock Bash startup files vary widely between distributions in which of them source which, under what circumstances, in what order and what additional configuration they perform. As such, the most reliable way to get Pyenv in all environments is to append Pyenv configuration commands to both .bashrc (for interactive shells) and the profile file that Bash would use (for login shells).

    First, add the commands to ~/.bashrc by running the following in your terminal:

    echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bashrc
    echo 'command -v pyenv >/dev/null || export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bashrc
    echo 'eval "$(pyenv init -)"' >> ~/.bashrc

    Then, if you have ~/.profile, ~/.bash_profile or ~/.bash_login, add the commands there as well. If you have none of these, add them to ~/.profile.

    • to add to ~/.profile:

      echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.profile
      echo 'command -v pyenv >/dev/null || export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.profile
      echo 'eval "$(pyenv init -)"' >> ~/.profile
    • to add to ~/.bash_profile:

      echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bash_profile
      echo '[[ -d $PYENV_ROOT/bin ]] && export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bash_profile
      echo 'eval "$(pyenv init -)"' >> ~/.bash_profile
  • For Zsh:

    echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.zshrc
    echo '[[ -d $PYENV_ROOT/bin ]] && export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.zshrc
    echo 'eval "$(pyenv init -)"' >> ~/.zshrc

    If you wish to get Pyenv in noninteractive login shells as well, also add the commands to ~/.zprofile or ~/.zlogin.

  • For Fish shell:

    If you have Fish 3.2.0 or newer, execute this interactively:

    set -Ux PYENV_ROOT $HOME/.pyenv
    fish_add_path $PYENV_ROOT/bin

    Otherwise, execute the snippet below:

    set -Ux PYENV_ROOT $HOME/.pyenv
    set -U fish_user_paths $PYENV_ROOT/bin $fish_user_paths

    Now, add this to ~/.config/fish/config.fish:

    pyenv init - | source

Bash warning: There are some systems where the BASH_ENV variable is configured to point to .bashrc. On such systems, you should almost certainly put the eval "$(pyenv init -)" line into .bash_profile, and not into .bashrc. Otherwise, you may observe strange behaviour, such as pyenv getting into an infinite loop. See #264 for details.

Proxy note: If you use a proxy, export http_proxy and https_proxy, too.

Restart your shell

for the PATH changes to take effect.

exec "$SHELL"

Install Python build dependencies

Install Python build dependencies before attempting to install a new Python version.

You can now begin using Pyenv.


Usage

Install additional Python versions

To install additional Python versions, use pyenv install.

For example, to download and install Python 3.10.4, run:

pyenv install 3.10.4

Running pyenv install -l gives the list of all available versions.

NOTE: Most Pyenv-provided Python releases are source releases and are built from source as part of installation (that's why you need Python build dependencies preinstalled). You can pass options to Python's configure and compiler flags to customize the build, see Special environment variables in Python-Build's README for details.

NOTE: If you are having trouble installing a Python version, please visit the wiki page about Common Build Problems.

NOTE: If you want to use proxy for download, please set the http_proxy and https_proxy environment variables.

NOTE: If you'd like a faster interpreter at the cost of longer build times, see Building for maximum performance in Python-Build's README.

Prefix auto-resolution to the latest version

All Pyenv subcommands except uninstall automatically resolve full prefixes to the latest version in the corresponding version line.

pyenv install picks the latest known version, while other subcommands pick the latest installed version.

E.g. to install and then switch to the latest 3.10 release:

pyenv install 3.10
pyenv global 3.10

You can run pyenv latest -k <prefix> to see how pyenv install would resolve a specific prefix, or pyenv latest <prefix> to see how other subcommands would resolve it.

See the pyenv latest documentation for details.

Python versions with extended support

For the following Python releases, Pyenv applies user-provided patches that add support for some newer environments. Though we don't actively maintain those patches, since existing releases never change, it's safe to assume that they will continue working until there are further incompatible changes in a later version of those environments.

  • 3.7.8-3.7.15, 3.8.4-3.8.12, 3.9.0-3.9.7 : XCode 13.3
  • 3.5.10, 3.6.15 : MacOS 11+ and XCode 13.3
  • 2.7.18 : MacOS 10.15+ and Apple Silicon

Switch between Python versions

To select a Pyenv-installed Python as the version to use, run one of the following commands:

E.g. to select the above-mentioned newly-installed Python 3.10.4 as your preferred version to use:

pyenv global 3.10.4

Now whenever you invoke python, pip etc., an executable from the Pyenv-provided 3.10.4 installation will be run instead of the system Python.

Using "system" as a version name would reset the selection to your system-provided Python.

See Understanding shims and Understanding Python version selection for more details on how the selection works and more information on its usage.

Uninstall Python versions

As time goes on, you will accumulate Python versions in your $(pyenv root)/versions directory.

To remove old Python versions, use pyenv uninstall <versions>.

Alternatively, you can simply rm -rf the directory of the version you want to remove. You can find the directory of a particular Python version with the pyenv prefix command, e.g. pyenv prefix 2.6.8. Note however that plugins may run additional operations on uninstall which you would need to do by hand as well. E.g. Pyenv-Virtualenv also removes any virtual environments linked to the version being uninstalled.

Other operations

Run pyenv commands to get a list of all available subcommands. Run a subcommand with --help to get help on it, or see the Commands Reference.

Note that Pyenv plugins that you install may add their own subcommands.

Upgrading

Upgrading with Homebrew

If you've installed Pyenv using Homebrew, upgrade using:

brew upgrade pyenv

To switch from a release to the latest development head of Pyenv, use:

brew uninstall pyenv
brew install pyenv --head

then you can upgrade it with brew upgrade pyenv as usual.

Upgrading with Installer or Git checkout

If you've installed Pyenv with Pyenv-installer, you likely have the Pyenv-Update plugin that would upgrade Pyenv and all installed plugins:

pyenv update

If you've installed Pyenv using Pyenv-installer or Git checkout, you can also upgrade your installation at any time using Git.

To upgrade to the latest development version of pyenv, use git pull:

cd $(pyenv root)
git pull

To upgrade to a specific release of Pyenv, check out the corresponding tag:

cd $(pyenv root)
git fetch
git tag
git checkout v0.1.0

Uninstalling pyenv

The simplicity of pyenv makes it easy to temporarily disable it, or uninstall from the system.

  1. To disable Pyenv managing your Python versions, simply remove the pyenv init invocations from your shell startup configuration. This will remove Pyenv shims directory from PATH, and future invocations like python will execute the system Python version, as it was before Pyenv.

    pyenv will still be accessible on the command line, but your Python apps won't be affected by version switching.

  2. To completely uninstall Pyenv, remove all Pyenv configuration lines from your shell startup configuration, and then remove its root directory. This will delete all Python versions that were installed under the $(pyenv root)/versions/ directory:

    rm -rf $(pyenv root)

    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
    

Pyenv plugins

Pyenv provides a simple way to extend and customize its functionality with plugins -- as simple as creating a plugin directory and dropping a shell script on a certain subpath of it with whatever extra logic you need to be run at certain moments.

The main idea is that most things that you can put under $PYENV_ROOT/<whatever> you can also put under $PYENV_ROOT/plugins/your_plugin_name/<whatever>.

See Plugins on the wiki on how to install and use plugins as well as a catalog of some useful existing plugins for common needs.

See Authoring plugins on the wiki on writing your own plugins.

Advanced Configuration

Skip this section unless you must know what every line in your shell profile is doing.

Also see the Environment variables section for the environment variables that control Pyenv's behavior.

pyenv init is the only command that crosses the line of loading extra commands into your shell. Coming from RVM, some of you might be opposed to this idea. Here's what eval "$(pyenv init -)" actually does:

  1. Sets up the shims path. This is what allows Pyenv to intercept and redirect invocations of python, pip etc. transparently. It prepends $(pyenv root)/shims to your $PATH. It also deletes any other instances of $(pyenv root)/shims on PATH which allows to invoke eval "$(pyenv init -)" multiple times without getting duplicate PATH entries.

  2. Installs autocompletion. This is entirely optional but pretty useful. Sourcing $(pyenv root)/completions/pyenv.bash will set that up. There are also completions for Zsh and Fish.

  3. Rehashes shims. From time to time you'll need to rebuild your shim files. Doing this on init makes sure everything is up to date. You can always run pyenv rehash manually.

  4. Installs pyenv into the current shell as a shell function. This bit is also optional, but allows pyenv and plugins to change variables in your current shell. This is required for some commands like pyenv shell to work. The sh dispatcher doesn't do anything crazy like override cd or hack your shell prompt, but if for some reason you need pyenv to be a real script rather than a shell function, you can safely skip it.

eval "$(pyenv init --path)" only does items 1 and 3.

To see exactly what happens under the hood for yourself, run pyenv init - or pyenv init --path.

eval "$(pyenv init -)" is supposed to run at any interactive shell's startup (including nested shells -- e.g. those invoked from editors) so that you get completion and convenience shell functions.

eval "$(pyenv init --path)" can be used instead of eval "$(pyenv init -)" to just enable shims, without shell integration. It can also be used to bump shims to the front of PATH after some other logic has prepended stuff to PATH that may shadow Pyenv's shims.

  • In particular, in Debian-based distributions, the stock ~/.profile prepends per-user bin directories to PATH after having sourced ~/.bashrc. This necessitates appending a pyenv init call to ~/.profile as well as ~/.bashrc in these distributions because the system's Pip places executables for modules installed by a non-root user into those per-user bin directories.

Using Pyenv without shims

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.

You can manually execute or symlink them as required, or you can use pyenv exec <command> whenever you want <command> to be affected by Pyenv's version selection as currently configured.

pyenv exec works by prepending $(pyenv root)/versions/<selected version>/bin to PATH in the <command>'s environment, the same as what e.g. RVM does.

Environment variables

You can affect how Pyenv operates with the following environment variables:

name default description
PYENV_VERSION Specifies the Python version to be used.
Also see pyenv shell
PYENV_ROOT ~/.pyenv Defines the directory under which Python versions and shims reside.
Also see pyenv root
PYENV_DEBUG Outputs debug information.
Also as: pyenv --debug <subcommand>
PYENV_HOOK_PATH see wiki Colon-separated list of paths searched for pyenv hooks.
PYENV_DIR $PWD Directory to start searching for .python-version files.

See also Special environment variables in Python-Build's README for environment variables that can be used to customize the build.


Development

The pyenv source code is hosted on GitHub. It's clean, modular, and easy to understand, even if you're not a shell hacker.

Tests are executed using Bats:

bats test
bats/test/<file>.bats

Contributing

Feel free to submit pull requests and file bugs on the issue tracker.

See CONTRIBUTING.md for more details on submitting changes.

Version History

See CHANGELOG.md.

License

The MIT License

pyenv-virtualenv's People

Contributors

ackalker avatar adamscharf avatar aiguofer avatar alanyee avatar andrew-christianson avatar anton-petrov avatar aristide-n avatar bartoszj avatar bcb avatar blueyed avatar daogilvie avatar elijahlynn avatar ericvw avatar faho avatar fgimian avatar galonsky avatar gauravtalreja1 avatar honza avatar jack-mcivor avatar jcrben avatar lmmarsano avatar native-api avatar puhitaku avatar pygeek avatar s0undt3ch avatar scop avatar shangsunset avatar silverjam avatar wwwjfy avatar yyuu avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

pyenv-virtualenv's Issues

Commands not available when using `--system-site-packages`

I am trying to setup a virtualenv with --system-site-packages to use compiled/pre-built packages, and noticed that e.g. ipython fails to run with:

% pyenv virtualenv --system-site-packages 3.4.2 paperwork3
...
% ipython
pyenv: ipython: command not found

The `ipython' command exists in these Python versions:
...

Trying to install it skips it, because it appears to be installed already.

Could pyenv somehow handle this, especially after trying to (re-)install it?

Pyenv deactivate not working

I am using Python 3.4.1 and installed pyenv manually and via homebrew on my Mac OSX running v 10.9.3. After creating a virtualenv and then activating it, which all works. I have a problem with deactivating. When I run 'pyenv deactivate' nothing happens and my shell still shows me as being in the virtualenv.

Any ideas to fix this? Thanks. If I do 'pyenv shell --unset' while in a virtualenv works to 'deactivate'.

Running pyenv deactivate in debug. Hiding my directory name from web scrapers.

++ [pyenv:15] type -p greadlink readlink
++ [pyenv:15] head -1

  • [pyenv:15] READLINK=/usr/bin/readlink
  • [pyenv:16] '[' -z /usr/bin/readlink ']'
  • [pyenv:21] unset GREP_OPTIONS
  • [pyenv:41] '[' -z /Users/HIDDEN/.pyenv ']'
  • [pyenv:44] PYENV_ROOT=/Users/HIDDEN/.pyenv
  • [pyenv:46] export PYENV_ROOT
  • [pyenv:48] '[' -z '' ']'
    ++ [pyenv:49] pwd
  • [pyenv:49] PYENV_DIR=/Users/HIDDEN
  • [pyenv:58] export PYENV_DIR
  • [pyenv:61] shopt -s nullglob
    ++ [pyenv:63] abs_dirname /Users/HIDDEN/.pyenv/bin/pyenv
    +++ [pyenv:28] pwd
    ++ [pyenv:28] local cwd=/Users/HIDDEN
    ++ [pyenv:29] local path=/Users/HIDDEN/.pyenv/bin/pyenv
    ++ [pyenv:31] '[' -n /Users/HIDDEN/.pyenv/bin/pyenv ']'
    ++ [pyenv:32] cd /Users/HIDDEN/.pyenv/bin
    ++ [pyenv:33] local name=pyenv
    +++ [pyenv:34] resolve_link pyenv
    +++ [pyenv:24] /usr/bin/readlink pyenv
    ++ [pyenv:34] path=../libexec/pyenv
    ++ [pyenv:31] '[' -n ../libexec/pyenv ']'
    ++ [pyenv:32] cd ../libexec
    ++ [pyenv:33] local name=pyenv
    +++ [pyenv:34] resolve_link pyenv
    +++ [pyenv:24] /usr/bin/readlink pyenv
    +++ [pyenv:34] true
    ++ [pyenv:34] path=
    ++ [pyenv:31] '[' -n '' ']'
    ++ [pyenv:37] pwd
    ++ [pyenv:38] cd /Users/HIDDEN
  • [pyenv:63] bin_path=/Users/HIDDEN/.pyenv/libexec
  • [pyenv:64] for plugin_bin in '"${PYENV_ROOT}/plugins/"*/bin'
  • [pyenv:65] bin_path=/Users/HIDDEN/.pyenv/libexec:/Users/HIDDEN/.pyenv/plugins/pyenv-virtualenv/bin
  • [pyenv:64] for plugin_bin in '"${PYENV_ROOT}/plugins/"*/bin'
  • [pyenv:65] bin_path=/Users/HIDDEN/.pyenv/libexec:/Users/HIDDEN/.pyenv/plugins/pyenv-virtualenv/bin:/Users/HIDDEN/.pyenv/plugins/python-build/bin
  • [pyenv:67] export PATH=/Users/HIDDEN/.pyenv/libexec:/Users/HIDDEN/.pyenv/plugins/pyenv-virtualenv/bin:/Users/HIDDEN/.pyenv/plugins/python-build/bin:/Users/HIDDEN/.pyenv/versions/test/bin:/Users/HIDDEN/.pyenv/shims:/Users/HIDDEN/.pyenv/bin:/Users/HIDDEN/.rvm/gems/ruby-2.1.2/bin:/Users/HIDDEN/.rvm/gems/ruby-2.1.2@global/bin:/Users/HIDDEN/.rvm/rubies/ruby-2.1.2/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Users/HIDDEN/.rvm/bin
  • [pyenv:67] PATH=/Users/HIDDEN/.pyenv/libexec:/Users/HIDDEN/.pyenv/plugins/pyenv-virtualenv/bin:/Users/HIDDEN/.pyenv/plugins/python-build/bin:/Users/HIDDEN/.pyenv/versions/test/bin:/Users/HIDDEN/.pyenv/shims:/Users/HIDDEN/.pyenv/bin:/Users/HIDDEN/.rvm/gems/ruby-2.1.2/bin:/Users/HIDDEN/.rvm/gems/ruby-2.1.2@global/bin:/Users/HIDDEN/.rvm/rubies/ruby-2.1.2/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Users/HIDDEN/.rvm/bin
  • [pyenv:69] hook_path=:/Users/HIDDEN/.pyenv/pyenv.d:/usr/local/etc/pyenv.d:/etc/pyenv.d:/usr/lib/pyenv/hooks
  • [pyenv:73] export PYENV_HOOK_PATH=:/Users/HIDDEN/.pyenv/pyenv.d:/usr/local/etc/pyenv.d:/etc/pyenv.d:/usr/lib/pyenv/hooks
  • [pyenv:73] PYENV_HOOK_PATH=:/Users/HIDDEN/.pyenv/pyenv.d:/usr/local/etc/pyenv.d:/etc/pyenv.d:/usr/lib/pyenv/hooks
  • [pyenv:75] shopt -u nullglob
  • [pyenv:78] command=sh-deactivate
  • [pyenv:79] case "$command" in
    ++ [pyenv:87] command -v pyenv-sh-deactivate
  • [pyenv:87] command_path=/Users/HIDDEN/.pyenv/plugins/pyenv-virtualenv/bin/pyenv-sh-deactivate
  • [pyenv:88] '[' -z /Users/HIDDEN/.pyenv/plugins/pyenv-virtualenv/bin/pyenv-sh-deactivate ']'
  • [pyenv:93] shift 1
  • [pyenv:94] exec /Users/HIDDEN/.pyenv/plugins/pyenv-virtualenv/bin/pyenv-sh-deactivate
    ++ [pyenv-sh-deactivate:12] basename bash
  • [pyenv-sh-deactivate:12] shell=bash
  • [pyenv-sh-deactivate:13] case "$shell" in
  • [pyenv-sh-deactivate:15] echo 'declare -f deactivate 1>/dev/null 2>&1 && deactivate;'
  • [pyenv-sh-deactivate:18] '[' -z 1 ']'

Deleting Virtual Environments

Hi @yyuu! Love the tool, one question. Is the only way to remove a venv created by pyenv virtualenv by deleting the folder in ~/.pyenv/versions?

Creating a 3.4.0 virtualenv fails under OS X Yosemite

It seems to fail installing pip. I got the following in ~/.pip/pip.log:

------------------------------------------------------------
-c run on Sat Nov  8 11:48:21 2014
Ignoring indexes: https://pypi.python.org/simple/
Downloading/unpacking setuptools
  URLs to search for versions for setuptools:
  Skipping link . (from -f); not a file
  Skipping link /Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/site-packages (from -f); not a file
  Skipping link /Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/site-packages/virtualenv_support (from -f); not a file
  Skipping link file:///Users/valrus/.pyenv/cache/pip-1.5.6.tar.gz; wrong project name (not setuptools)
  Skipping link file:///Users/valrus/.pyenv/cache/Python-2.7.7.tgz; wrong project name (not setuptools)
  Found link file:///Users/valrus/.pyenv/cache/setuptools-5.0.tar.gz, version: 5.0
  Skipping link file:///Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/site-packages/__pycache__; not a file
  Skipping link file:///Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/site-packages/_markerlib; not a file
  Skipping link file:///Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/site-packages/clonevirtualenv.py; unknown archive format: .py
  Skipping link file:///Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/site-packages/easy_install.py; unknown archive format: .py
  Skipping link file:///Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/site-packages/IPython; not a file
  Skipping link file:///Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/site-packages/ipython-1.2.1-py3.4.egg-info; unknown archive format: .egg-info
  Skipping link file:///Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/site-packages/pip; not a file
  Skipping link file:///Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/site-packages/pip-1.5.4.dist-info; unknown archive format: .dist-info
  Skipping link file:///Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/site-packages/pkg_resources.py; unknown archive format: .py
  Skipping link file:///Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/site-packages/README; not a file
  Skipping link file:///Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/site-packages/setuptools; not a file
  Skipping link file:///Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/site-packages/setuptools-2.1.dist-info; unknown archive format: .dist-info
  Skipping link file:///Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/site-packages/stevedore; not a file
  Skipping link file:///Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/site-packages/stevedore-0.14.1-py3.4.egg-info; unknown archive format: .egg-info
  Skipping link file:///Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/site-packages/virtualenv-1.11.4.dist-info; unknown archive format: .dist-info
  Skipping link file:///Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/site-packages/virtualenv.py; unknown archive format: .py
  Skipping link file:///Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/site-packages/virtualenv_clone-0.2.4-py3.4.egg-info; unknown archive format: .egg-info
  Skipping link file:///Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/site-packages/virtualenv_support; not a file
  Skipping link file:///Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/site-packages/virtualenvwrapper; not a file
  Skipping link file:///Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/site-packages/virtualenvwrapper-4.2-py3.4-nspkg.pth; unknown archive format: .pth
  Skipping link file:///Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/site-packages/virtualenvwrapper-4.2-py3.4.egg-info; unknown archive format: .egg-info
  Skipping link file:///Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/site-packages/virtualenv_support/__init__.py; unknown archive format: .py
  Skipping link file:///Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/site-packages/virtualenv_support/__pycache__; not a file
  Skipping link file:///Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/site-packages/virtualenv_support/pip-1.5.4-py2.py3-none-any.whl; wrong project name (not setuptools)
  Found link file:///Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/site-packages/virtualenv_support/setuptools-2.2-py2.py3-none-any.whl, version: 2.2
  Local files found: /Users/valrus/.pyenv/cache/setuptools-5.0.tar.gz, /Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/site-packages/virtualenv_support/setuptools-2.2-py2.py3-none-any.whl
  Using version 5.0 (newest of versions: 5.0, 2.2)
  Running setup.py (path:/Users/valrus/.pyenv/versions/tweepy/build/setuptools/setup.py) egg_info for package setuptools
    running egg_info
    creating pip-egg-info/setuptools.egg-info
    writing top-level names to pip-egg-info/setuptools.egg-info/top_level.txt
    writing requirements to pip-egg-info/setuptools.egg-info/requires.txt
    writing dependency_links to pip-egg-info/setuptools.egg-info/dependency_links.txt
    writing entry points to pip-egg-info/setuptools.egg-info/entry_points.txt
    writing pip-egg-info/setuptools.egg-info/PKG-INFO
    writing manifest file 'pip-egg-info/setuptools.egg-info/SOURCES.txt'
    warning: manifest_maker: standard file '-c' not found

    reading manifest file 'pip-egg-info/setuptools.egg-info/SOURCES.txt'
    reading manifest template 'MANIFEST.in'
    writing manifest file 'pip-egg-info/setuptools.egg-info/SOURCES.txt'
  Source in /Users/valrus/.pyenv/versions/tweepy/build/setuptools has version 5.0, which satisfies requirement setuptools
  skipping extra certs
  skipping extra ssl:sys_platform=='win32'
Downloading/unpacking pip
  URLs to search for versions for pip:
  Found link file:///Users/valrus/.pyenv/cache/pip-1.5.6.tar.gz, version: 1.5.6
  Skipping link file:///Users/valrus/.pyenv/cache/Python-2.7.7.tgz; wrong project name (not pip)
  Skipping link file:///Users/valrus/.pyenv/cache/setuptools-5.0.tar.gz; wrong project name (not pip)
  Found link file:///Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/site-packages/virtualenv_support/pip-1.5.4-py2.py3-none-any.whl, version: 1.5.4
  Skipping link file:///Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/site-packages/virtualenv_support/setuptools-2.2-py2.py3-none-any.whl; wrong project name (not pip)
  Local files found: /Users/valrus/.pyenv/cache/pip-1.5.6.tar.gz, /Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/site-packages/virtualenv_support/pip-1.5.4-py2.py3-none-any.whl
  Using version 1.5.6 (newest of versions: 1.5.6, 1.5.4)
  Running setup.py (path:/Users/valrus/.pyenv/versions/tweepy/build/pip/setup.py) egg_info for package pip
    /Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/distutils/dist.py:260: UserWarning: Unknown distribution option: 'tests_require'
      warnings.warn(msg)
    /Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/distutils/dist.py:260: UserWarning: Unknown distribution option: 'zip_safe'
      warnings.warn(msg)
    /Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/distutils/dist.py:260: UserWarning: Unknown distribution option: 'extras_require'
      warnings.warn(msg)
    /Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/distutils/dist.py:260: UserWarning: Unknown distribution option: 'entry_points'
      warnings.warn(msg)
    usage: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
       or: -c --help [cmd1 cmd2 ...]
       or: -c --help-commands
       or: -c cmd --help

    error: invalid command 'egg_info'
    Complete output from command python setup.py egg_info:
    /Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/distutils/dist.py:260: UserWarning: Unknown distribution option: 'tests_require'

  warnings.warn(msg)

/Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/distutils/dist.py:260: UserWarning: Unknown distribution option: 'zip_safe'

  warnings.warn(msg)

/Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/distutils/dist.py:260: UserWarning: Unknown distribution option: 'extras_require'

  warnings.warn(msg)

/Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/distutils/dist.py:260: UserWarning: Unknown distribution option: 'entry_points'

  warnings.warn(msg)

usage: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]

   or: -c --help [cmd1 cmd2 ...]

   or: -c --help-commands

   or: -c cmd --help



error: invalid command 'egg_info'

----------------------------------------
Cleaning up...
  Removing temporary dir /Users/valrus/.pyenv/versions/tweepy/build...
Command python setup.py egg_info failed with error code 1 in /Users/valrus/.pyenv/versions/tweepy/build/pip
Exception information:
Traceback (most recent call last):
  File "/Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/site-packages/virtualenv_support/pip-1.5.4-py2.py3-none-any.whl/pip/basecommand.py", line 122, in main
    status = self.run(options, args)
  File "/Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/site-packages/virtualenv_support/pip-1.5.4-py2.py3-none-any.whl/pip/commands/install.py", line 278, in run
    requirement_set.prepare_files(finder, force_root_egg_info=self.bundle, bundle=self.bundle)
  File "/Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/site-packages/virtualenv_support/pip-1.5.4-py2.py3-none-any.whl/pip/req.py", line 1229, in prepare_files
    req_to_install.run_egg_info()
  File "/Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/site-packages/virtualenv_support/pip-1.5.4-py2.py3-none-any.whl/pip/req.py", line 325, in run_egg_info
    command_desc='python setup.py egg_info')
  File "/Users/valrus/.pyenv/versions/3.4.0/lib/python3.4/site-packages/virtualenv_support/pip-1.5.4-py2.py3-none-any.whl/pip/util.py", line 697, in call_subprocess
    % (command_desc, proc.returncode, cwd))
pip.exceptions.InstallationError: Command python setup.py egg_info failed with error code 1 in /Users/valrus/.pyenv/versions/tweepy/build/pip

Cannot properly uninstall virtualenv

Hi,

I have been messing around with this for a few minutes and I can't quite figure out what the issue is. So I made a virtualenv to test out pyechonest for my brother, and once I was done I went to delete the virtualenv. First I simply deleted the directory containing the virtualenv. I have done this in the past and it has worked fine.

Now I get spammed with the following messages every time I execute any command in the terminal:

pyenv: version `echonest2' is not installed
pyenv: version `echonest2' not installed
pyenv: version `echonest2' is not installed

echonest2 is the name of the virtualenv that I created.

I have also tried using pyenv uninstall echonest2 and that didn't seem to help either. The only way I can get these messages to stop showing up is to take the stuff related to pyenv out of my .bashrc. I have even tried completely uninstalling pyenv (by deleting the .pyenv) directory, and that still didn't solve it.

Hopefully this makes sense.

Thanks!

P.S. I am running Arch Linux if that makes any difference.

New virtualenv installs all site packages by default

I can't seem to create a virtualenv without all the site packages being included. I used the --no-site-packages option and that worked fine last night. For some reason today, that option is no longer available. It says new envs will have no site packages included by default but it doesnt seem to be the case for me.

Can't create a virtualenv with python3.4

With the default python2.7 it works fine, but it fails when I specify python3
Both pythons, pyenv and pyenv-virtualenv have been installed through brew.
The error message seems quite clear but I don't have a clue how to solve it.

$ pyenv virtualenv --python=/usr/local/bin/python3  matrix
Running virtualenv with interpreter /usr/local/bin/python3
Using base prefix '/usr/local/Cellar/python3/3.4.1/Frameworks/Python.framework/Versions/3.4'
New python executable in /Users/hernan/.pyenv/versions/matrix/bin/python3.4
Also creating executable in /Users/hernan/.pyenv/versions/matrix/bin/python
Failed to import the site module
Traceback (most recent call last):
  File "/Users/hernan/.pyenv/versions/matrix/bin/../lib/python3.4/site.py", line 67, in <module>
    import os
  File "/Users/hernan/.pyenv/versions/matrix/bin/../lib/python3.4/os.py", line 614, in <module>
    from _collections_abc import MutableMapping
ImportError: No module named '_collections_abc'
ERROR: The executable /Users/hernan/.pyenv/versions/matrix/bin/python3.4 is not functioning
ERROR: It thinks sys.prefix is '/Users/hernan/.pyenv/cache' (should be '/Users/hernan/.pyenv/versions/matrix')
ERROR: virtualenv is not compatible with this system or executable
$

error: pyenv activate

I've installed pyenv and pyenv-virtualenv. pyenv seems to be working great, and it appears I am able to create a virtualenv, but I can not seem to activate the virtualenv.

test3.3 >> pyenv virtualenvs
  py276 (created from /Users/insomniac/.pyenv/versions/2.7.6)
  py333 (created from /Users/insomniac/.pyenv/versions/3.3.3)
test3.3 >> pyenv activate py333
pyenv: no such command `activate'

How can I activate the virtual env? Also, is there a way to auto-activate and auto-deactivate the virtual environment when I go in and out of the directory?

Thanks,
C.

pyenv-virtualenv deactivate automatically any virtualenvironment

If I activate any environment without pyenv shell env then it'll automatically deactivated with next command

$ cd ~/data
$ virtualenv venv
$ . venv/bin/activate
$ echo $VIRTUAL_ENV
/home/user/data/venv
$ pip install pyflake8 #actually any command
$ echo $VIRTUAL_ENV

$ echo :(

My configuration

export PATH=$HOME/.pyenv/bin:$PATH
if type pyenv 1> /dev/null 2>&1
then
    eval "$(pyenv init -)"
    eval "$(pyenv virtualenv-init -)"
fi

pyenv-virtualenv breaks pyenv

I installed pyenv ealier and everything was working great. I installed python2.7.6 with pyenv as per the documentation and tested it - everything was working fine. Every time I went into the test2.7 folder and checked the python version everything seemed correct - python 2.7.6 was being used.

After installing the pyenv-virtualenv plugin, the system version of python is being used, not the one set with pyenv.

I did not make any changes to my .bash_profile after the initial installation of pyenv, so I'm not sure why this has stopped working.

test2.7 >> cat .python-version 
2.7.6
test2.7 >> pyenv local
2.7.6
test2.7 >> python
Python 2.7.5 (default, Aug 25 2013, 00:04:04) 
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

error: Could not find an activated virtualenv (required).

For starters, I must state that I'm new at working with python in virtual environments, so please forgive me if I'm missing something obvious.

I want to create isolated projects with different versions of python and python packages.

I installed pyenv and that seems to be working fine. I installed various versions of python and set "pyenv local 3.3.3" and when I check the python version, everything seems correct.

I then installed pyenv-virtualenv, since the documentation states that 'pyenv' does not manage the virtual environments and to use 'pyenv-virtualenv' to make it easier.

I ran brew the following command to install pyenv-virtualenv:
~>> brew install pyenv-virtualenv
and everything seemed to run ok.

I then created and changed into a new directory 'test'. I ran the command based on the documentation and get the following error:

Repo >> mkdir test
Repo >> cd test
test >> pyenv virtualenv 2.7.6 mytestenv
Could not find an activated virtualenv (required).

I was under the assumption that pyenv virtualenv would create a virtual environment called 'mytestenv' using python 2.7.6. I'm not sure if I need to add something to my .bash_profile in order to get this to work. I have a lot of stuff in there from before since I had previously installed the regular version of virtualenv and virtualenvwrapper.

Can someone please explain how this is supposed to be used so I do not get the error. I've looked online for a couple hours and can not seem to find clear documentation.

Thanks,
Carolyn

Post install package for every virtualenv created

Is it possible to have a post install hook so that every time a new virtualenv is created a package is installed too?

The use case is simple: i'd like - in the same way pip is installed - to have iPython installed automatically with every pyenv virtualenv created.

How does the auto activation/ deactivation works?

I'm running Mac 10.9.5 and i did the installation as below:

brew install pyenv
eval "$(pyenv init -)" >> ~/.bashrc
brew install pyenv-virtualenv
eval "$(pyenv virtualenv-init -)" >> ~/.bashrc

The installation home is all under

pyenv versions
* system (set by /usr/local/opt/pyenv/version)
  3.4.2
  ra1

[dani@localhost in ~]# ll /usr/local/opt/pyenv*
lrwxr-xr-x  1 dani  admin    24B Oct 22 16:27 /usr/local/opt/pyenv -> ../Cellar/pyenv/20141012
lrwxr-xr-x  1 dani  admin    35B Oct 22 16:38 /usr/local/opt/pyenv-virtualenv -> ../Cellar/pyenv-virtualenv/20141012

I read the other issues - #47 , #48, #32 , #33 and i've followed the same steps as in #32 (i get this are the manual steps)

[dani@localhost in ~]# pyenv versions
* system (set by /usr/local/opt/pyenv/version)
  3.4.2
  ra1
[dani@localhost in ~]# python -V
Python 2.7.6
[dani@localhost in ~]# echo PYENV_ACTIVATED
PYENV_ACTIVATED
[dani@localhost in ~]# echo $PYENV_ACTIVATED

[dani@localhost in ~]# echo $PYENV_DEACTIVATED

[dani@localhost in ~]# echo $PYENV_VIRTUALENV_INIT
1
[dani@localhost in ~]# pyenv activate ra1
(ra1) [dani@localhost in ~]# python -V
Python 3.4.2
(ra1) [dani@localhost in ~]# echo $PYENV_ACTIVATED

(ra1) [dani@localhost in ~]# echo $PYENV_DEACTIVATED

(ra1) [dani@localhost in ~]# echo $PYENV_VERSION
ra1
(ra1) [dani@localhost in ~]# pyenv deactivate
[dani@localhost in ~]# echo $PYENV_VERSION
ra1
[dani@localhost in ~]# echo $PYENV_DEACTIVATED

[dani@localhost in ~]# echo $PYENV_ACTIVATED

[dani@localhost in ~]# pyenv version
ra1 (set by PYENV_VERSION environment variable)
[dani@localhost in ~]# pyenv versions
  system
  3.4.2
* ra1 (set by PYENV_VERSION environment variable)
[dani@localhost in ~]#

BUT because the above behavior, when i'm trying to uninstall the virtual env i get this error

[dani@localhost in ~]# pyenv uninstall ra1
pyenv: remove /usr/local/opt/pyenv/versions/ra1? y
[dani@localhost in ~]# pyenv versions
pyenv: version `ra1' is not installed
  system
  3.4.2

In #47 you mentioned,

As you mentioned, PYENV_DEACTIVATED should not persist after automatically triggered deactivation. I'll try to fix it in #47.

hence my question: _what is the working flow for the auto activation/ deactivation? Do i need to be inside the PYENV_ROOT in order for auto activation to kick in?_

In addition to this issue, according to the README file, the pyenv-virtualenv should be registered as a plugin inside pyenv, is this a bug in the brew formula's installation?

[dani@localhost in ~]# ll /usr/local/opt/pyenv/plugins/
total 8
lrwxr-xr-x  1 dani  admin    61B Oct 22 16:27 python-build -> /usr/local/Cellar/pyenv/20141012/default-plugins/python-build

pyenv not playing nice with brew

I installed python 2.7.6 and python 3.3.3 with pyenv.

Now when I run brew doctor I get the following warning:

Warning: "config" scripts exist outside your system or Homebrew directories.
`./configure` scripts often look for *-config scripts to determine if
software packages are installed, and what additional flags to use when
compiling and linking.

Having additional scripts in your path can confuse software installed via
Homebrew if the config script overrides a system or Homebrew provided
script of the same name. We found the following "config" scripts:

    /Users/insomniac/.pyenv/shims/python-config
    /Users/insomniac/.pyenv/shims/python2-config
    /Users/insomniac/.pyenv/shims/python2.7-config
    /Users/insomniac/.pyenv/shims/python3-config
    /Users/insomniac/.pyenv/shims/python3.3-config
    /Users/insomniac/.pyenv/shims/python3.3m-config

How can this be fixed so it plays nice with brew?
C.

PATH environment variable does not get updated

pyenv-virtualenv does not seem to handle scripts that gets installed in the bin directory. Albeit the installation procedure seems to be fine, the plugin does not actually export in the PATH environment variable the bin path.

For example if I try to install Twisted, from the setup logs I can clearly see that scripts are correctly installed under /Users/whatever/.pyenv/versions/demo-2.7.5/bin/twistd but the environment variable PATH is not set to include the folder /Users/whatever/.pyenv/versions/demo-2.7.5/bin/.

pyenv-virtualenv slows down zsh considerably

If eval "$(pyenv virtualenv-init -)" is in my zshenv, every time a command finishes there is a delay of about a second. Even hitting the enter key to cause another prompt without entering a command is slow.

Judging by what init does to the shell, perhaps this is because this command is slow:
pyenv activate --no-error --verbose

I do not have PYENV_ACTIVATE set, so that branch of the init logic would be hit.

2to3 not found in virtualenv, causing an error during package installation via pip

Hi,

I just installed a 3.3.5 version in pyenv on a Debian Wheezy. Then I made a virtualenv using pyenv-virtualenv. And the last part, I did a pip install -r requirements.txt.

And I got this error while installing a dependancy:

subprocess.CalledProcessError: Command '['2to3', '-wn', 'build/lib/logilab/common/test/data']' returned non-zero exit status 127

When I execute 2to3 command, I have this result:

(tickets) root@infra-tool01:/srv/tickets/tickets# 2to3
pyenv: 2to3: command not found

The `2to3' command exists in these Python versions:
  3.3.5

It seems 2to3 command executed is the one in shims:

(tickets) root@infra-tool01:/srv/tickets/tickets# which 2to3
/srv/tickets/pyenv/shims/2to3

Here is my $PATH:

(tickets) root@infra-tool01:/srv/tickets/tickets# echo $PATH
/srv/tickets/pyenv/versions/tickets/bin:/srv/tickets/pyenv/shims:/srv/tickets/pyenv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

I did a pyenv rehash outside and inside the virtualenv, nothing changed.

Any idea?

Best regards,
Alexis.

Major problems with current version of pyenv-virtualenv

Hey there Yuu, hope you're well 😄

Since some of the latest commits, I've been having quite a few major problems with this extension I'm afraid.

My test system is a fresh install of Ubuntu Server 12.04 with the regular bash shell.

This output should explain the problems 😄

fots@fotsies-ubprecise-02:~$ pyenv versions
* system (set by /home/fots/.pyenv/version)
  2.7.7
  3.4.1
fots@fotsies-ubprecise-02:~$ python -V
Python 2.7.3
fots@fotsies-ubprecise-02:~$ pyenv global 2.7.7
fots@fotsies-ubprecise-02:~$ python -V
Python 2.7.7
fots@fotsies-ubprecise-02:~$ pyenv virtualenv newproject
New python executable in /home/fots/.pyenv/versions/newproject/bin/python
Installing setuptools, pip...done.
fots@fotsies-ubprecise-02:~$ pyenv activate newproject
(newproject)fots@fotsies-ubprecise-02:~$ python -V
Python 2.7.3
(newproject)fots@fotsies-ubprecise-02:~$ pyenv deactivate
(newproject)fots@fotsies-ubprecise-02:~$ unset PYENV_VERSION
fots@fotsies-ubprecise-02:~$ pyenv virtualenv 2.7.7 newproject2
New python executable in /home/fots/.pyenv/versions/newproject2/bin/python
Installing setuptools, pip...done.
fots@fotsies-ubprecise-02:~$ pyenv activate newproject2
(newproject2)fots@fotsies-ubprecise-02:~$ python -V
Python 2.7.3
(newproject2)fots@fotsies-ubprecise-02:~$

So in summary:

  • Creating a virtualenv always uses the system version of Python
  • Deactivating a virtualenv no longer correctly unsets the PYENV_VERSION environment variable

Your help would be greatly appreciated
Fotis

Anaconda 1.9.1 install detects Darwin-x86_64 architecture, returns error

On OS X 10.8.5, running pyenv install anaconda-1.9.1 returns:

ERRORPrecompiled binary of anaconda-1.9.1 is not available for Darwin-x86_64.

It appears that what should happen is that anaconda_architecture (in plugins/python-build/share/python-build/anaconda-1.9.1) should return MacOSX-x86_64; it returns Darwin-x86_64 instead.

"activate" command breaks fish-shell PS1

In my current oh-my-fish theme (numist) I type command in the second line, but when I activate my pyenv-virtualenv it breaks and goes back to the same line as the other info. Check the screenshot for details.

image

Activation / Deactivation of virtualenvs works only once

I have a project in which I created a .python-version file. In this case I have something like:

$ cat project/.python-version
project-2.7.8

Whenever I change my directory to the project root pyenv-virtualenv is invoked correctly. When I leave the virtual env is deactivated.

$ cd project
pyenv-virtualenv: activate project-2.7.8
(project-2.7.8) $ cd ..
pyenv-virtualenv: deactivate project-2.7.8

The problem is that if I re-enter in the project/ directory is not activated anymore.

$ cd project
# Nothing happens
$

It doesn't matter how many times I try, the activation seems to work only once. Successive attempts seem to ignore the virtualenv indicated in the .python-version file.

pyenv deactivate command doesn't work propery

Activating the virtualenv works perfectly but when in need to deactivate using "pyenv deactivate" command the PS1 remove the environment name but when you check which active version using "pyenv version" the deactivated environment is still active. Something maybe wrong.

screen shot 2014-12-22 at 6 50 56 pm

Activating virtualenvs fail with the fish shell

Hey there, I've noticed that activating a virtualenv on the fish shell doesn't work. I tested this with a fresh Ubuntu 14.04 install and a new copy of pyenv.

fots@fotsies-ubtrusty-01~> pyenv global 2.7.6
fots@fotsies-ubtrusty-01~> pyenv virtualenv flaskage
Downloading/unpacking virtualenv
  Downloading virtualenv-1.11.6-py2.py3-none-any.whl (1.6MB): 1.6MB downloaded
Installing collected packages: virtualenv
Successfully installed virtualenv
Cleaning up...
New python executable in /home/fots/.pyenv/versions/flaskage/bin/python
Installing setuptools, pip...done.
fots@fotsies-ubtrusty-01~> pyenv activate flaskage
pyenv: version `/home/fots/.pyenv/versions/flaskage/bin/activate.fish' not installed
fots@fotsies-ubtrusty-01~>

Activating the virtualenv manually seems to work:

fots@fotsies-ubtrusty-01~> . /home/fots/.pyenv/versions/flaskage/bin/activate.fish
(flaskage)fots@fotsies-ubtrusty-01~> which python
/home/fots/.pyenv/versions/flaskage/bin/python
(flaskage)fots@fotsies-ubtrusty-01~> pyenv deactivate
fots@fotsies-ubtrusty-01~>

Your help on this would be greatly appreciated! 😄
Fotis

Python 2.4.6 needs virtualenv 1.7.2

Hi everyone, I didn't find where to fix it.. in my pc I'm uninstalling / installing by hand with:
$ pyenv global 2.4.6
$ pip uninstall virtualenv
$ easy_install virtualenv==1.7.2

Could you please fix the version of virtualenv with python 2.4.6?

Virtualenv creation does not seem to work correctly

Hi!

I have been having some problems creating new virtualenvs using the pyenv-virtualenv plugin. If I issue the following command in terminal:
pyenv virtualenv 3.3.5 myenv
This is what the terminal outputs:

pyenv virtualenv [-f|--force] [-u|--upgrade] [VIRTUALENV_OPTIONS] <version> <virtualenv-name>
       pyenv virtualenv --version
       pyenv virtualenv --help

  -u/--upgrade     Upgrade existing virtualenv to use new version of Python,
                   assuming Python has been upgraded in-place.
  -f/--force       Install even if the version appears to be installed already

I'm certain that I am inputting the command correctly, as I have used this plugin before without any issues. I am running a fresh install of Ubuntu 14.04, and all of my pyenv packages are up to date. I'm hoping that this isn't just a stupid oversight on my part!

Matt

Unable to select which system Python version to use.

I have two system Pythons installed: 2.7.5 and 3.2. When creating a virtual env:

pyenv virtualenv system foo

I can't select which one to use. The default (2.7.5) is always used. I tried aliasing:

~$ alias python=python3
~$ pyenv virtualenv system foo

I also tried changing the python shim to always run python3 by changing the last line to:

exec "/home/tomas/.pyenv/libexec/pyenv" exec "python3" "$@"

right before creating the virtual env. In both cases, version 2.7.5 was still used. Creating the virtual env manually worked:

~$ pyenv shell system
~$ virtualenv -p `pyenv which python3` --system-site-packages .pyenv/versions/photo_organizer

pyenv activate/deactivate not working

I am having trouble activating a virtual environment with "pyenv activate".

I restarted my machine and am working in a fresh shell.
I have pyenv installed and it appears to be working correctly.

~ >> pyenv versions
  system
* 2.7.6 (set by /Users/insomniac/.pyenv/version)
  3.3.3

I create a new project and set the python version with pyenv:

>> mkdir myproj
>> cd myproj
myproj >> pyenv local 3.3.3
myproj >> pyenv local
3.3.3

I then create a virtualenv called "foo" and double check it was created

myproj >> pyenv virtualenv foo333

myproj >> pyenv virtualenvs
  foo333 (created from /Users/insomniac/.pyenv/versions/3.3.3)

If I list pyenv versions, it's showing in the list, so I assume the virtual environments are being saved in the same location (this is a bit confusing).

myproj >> pyenv versions
  system
  2.7.6
* 3.3.3 (set by /Users/insomniac/Repo/myproj/.python-version)
  foo333

If I try to active the "foo333" virtual environment for "myproject" I get the following error:

myproj >> pyenv activate foo333
pyenv: no such command `activate'

I restart my shell and try again with the same result:

myproj >> pyenv local
3.3.3
myproj >> pyenv virtualenvs
  foo333 (created from /Users/insomniac/.pyenv/versions/3.3.3)
myproj >> pyenv activate foo333
pyenv: no such command `activate'
myproj >> 

I am able to activate 'foo333' with the following command:

myproj >> source "$(pyenv prefix foo333)/bin/activate"
(foo333) myproj >>

If I try to deactivate - I can only use "deactivate" - I get the same error if I use pyenv deactivate

(foo333) myproj >> pyenv deactivate
pyenv: no such command `deactivate'

(foo333) myproj >> deactivate
myproj >> 

I installed pyenv-virtualenv this morning using "brew install".
Any ideas?

Thanks,
C.

Feature suggestion: clone virtualenv to new env

While working on different library version it would be extremely helpful to be able to clone an existing virtualenv.

Right now what I do is:

  1. pip freeze > requirements.txt in the current virtualenv
  2. pyenv virtualenv ...
  3. pyenv shell newvirtualenv
  4. pip install -r requirements.txt

Not too bad, but it could be easier.

Virtual env creation not working with very last version

On OpenSuse 12.1 with a custom pyenv home path.

There's no error :

pyenv virtualenv 2.6.8 custom_py2.6.8_2
New python executable in /datas/libs/pyenv/versions/custom_py2.6.8_2/bin/python
Installing setuptools, pip...done.

The new env directory isn't created in .../versions and isn't listed by pyenv versions.

The same command is ok with v20140110.1 tag.

Versions :

  • pyenv 0.4.0-20140110.1-8-g385d333
  • pyenv-virtualenv 20140110.1 (virtualenv 1.11)

pip list issue?

So I have a local python version within a folder (set by pyenv local 2.7.8) and I also have created a virtualenv using this command: pyenv virtualenv 2.7.8 venv278. (not active at the moment). Now I do pip list and sure enough I get the right result. Now I activate the virtualenv like so: pyenv activate venv278. and pip install a package (let's say django). while the virtualenv is still active I do pip list, and I see django package in the list. So far, so good. But when I deactivate the virtualenv and do pip list again, I can still see django in the list. Which I think is wrong. However when I restart the terminal and go to that directory again and do pip list (with virtualenv NOT activated yet) I get the correct result, i.e. the list without django!

I'm running mac os x (version 10.9.4) and installed pyenv through homebrew.

pyenv global not setting the env correctly

:~[103] > pyenv versions
  system
  3.4.1
  jython-2.5.3
:~[104] > python --version
Python 2.7.8
:~[105] > pyenv global 3.4.1
:~[106] > pyenv versions
  system
* 3.4.1 (set by /Users/christoperjung/.pyenv/version)
  jython-2.5.3
:~[107] > python --version
Python 2.7.8

It seems like pyenv global's not working properly. How can I fix this issue?

Use chpwd hook for _pyenv_virtualenv_hook / internal hook system with pyenv

I wonder if it would be a good idea to use the chpwd hook (instead of precmd (for zsh)) with the hook that gets installed via pyenv virtualenv init -:

_pyenv_virtualenv_hook () {
  if [ -n "$PYENV_ACTIVATE" ]
  then
    if [ "$(pyenv version-name)" = "system" ]
    then
      pyenv deactivate --no-error --verbose
      return 0
    fi
    if [ "$PYENV_ACTIVATE" != "$(pyenv prefix)" ]
    then
      if pyenv deactivate --no-error --verbose
      then
        pyenv activate --no-error --verbose || unset PYENV_DEACTIVATE
      else
        pyenv activate --no-error --verbose
      fi
    fi
  else
    if [ -z "$VIRTUAL_ENV" ] && [ "$PYENV_DEACTIVATE" != "$(pyenv prefix)" ]
    then
      pyenv activate --no-error --verbose
    fi
  fi
}

Alternatively, pyenv itself could have a hook system, where changing the version (e.g. via pyenv shell) would notify the pyenv-virtualenv plugin and that could call activate then (based on some config).

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/4224688-use-chpwd-hook-for-_pyenv_virtualenv_hook-internal-hook-system-with-pyenv?utm_campaign=plugin&utm_content=tracker%2F335155&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F335155&utm_medium=issues&utm_source=github).

Running Tox inside a pyenv virutalenv

It seems like you can't use Tox to test against multiple Python versions inside of a virtualenv created with pyenv-virtualenv. From what I can tell, this is because activating a pyenv-virtualenv sets the PYENV_VERSION to the named virtualenv, which makes all the other pythonX.Y shims invalid.

A complete example demonstrating this problem:

$> pyenv install 2.7.6
$> pyenv install 3.4.1
$> pyenv global 2.7.6 3.4.1
$> pyenv versions
  system
* 2.7.6 (set by /Users/andy/.pyenv/version)
* 3.4.1 (set by /Users/andy/.pyenv/version)

# NOTE, installing tox "globally" here and running it
# against 2.7.6 and 3.4.1 works fine because both
#2.7.6 and 3.4.1 are "activated" in the non-virtualenv
# environment

$> pyenv virtualenv 2.7.6 redis-py
$> pyenv activate redis-py
$> pyenv versions
  system
  2.7.6
  3.4.1
* redis-py (set by PYENV_VERSION environment variable)

# Now Tox (or any other program trying to call python3.4) will fail

$> python3.4
pyenv: python3.4: command not found

The `python3.4' command exists in these Python versions:
  3.4.1

I've gotten around this problem by using pyenv-virtualenvwrapper, which doesn't seem to use the pyenv versions system to create the virtualenv and doesn't set the PYENV_VERSION environment variable.

activate/deactivate script hooks?

I wanted to just confirm that there isn't any automatic facility in pyenv or pyenv-virtualenv for hooks like the way virtualenvwrapper provides postactivate and postdeactivate scripts. I'm mostly interested in the setting of environment variables when a version activates.

I'm fine with leaving virtualenvwrapper behind (or else I'd play with pyenv-virtualenvwrapper), but I figured I should find out for sure if there is any similar functionality available to me. I didn't see anything along these lines on https://github.com/yyuu/pyenv/wiki/Plugins

Thanks in advance for any info one way or the other!

Command for temporary environments

Some times we just want to try some library, it would be nice to have something along the lines of the following to easily create a disposable environment.

#!/bin/sh
# TODO: generate a unique name if none given
# TODO: allow to define a base environment
pyenv virtualenv "$1"

echo "Entering a new shell session with version '$1'"
echo "Press ctrl+d or exit to terminate it" 

export PYENV_VERSION="$1"
$SHELL

echo "Destroying temp version '$1'"
pyenv uninstall -f "$1"

Upgrading virtualenvs

I tried to upgrade 3.4.1 based virtualenv to 3.4.2:

Alexanders-MacBook-Air:~ lorddaedra$ pyenv virtualenv 3.4.2 byvshie
pyenv-virtualenv: /Users/lorddaedra/.pyenv/versions/byvshie already exists
continue with installation? (y/N) y

but it's still has python3.4 symlink to 3.4.1(not 3.4.2 as expected)

(byvshie) Alexanders-MacBook-Air:~ lorddaedra$ ls -al ~/.pyenv/versions/byvshie/bin/
total 272
drwxr-xr-x  34 lorddaedra  staff   1156 15 окт 13:56 .
drwxr-xr-x   6 lorddaedra  staff    204 15 окт 13:56 ..
drwxr-xr-x   8 lorddaedra  staff    272 15 окт 13:56 __pycache__
-rw-r--r--   1 lorddaedra  staff   2163 16 окт 02:56 activate
-rw-r--r--   1 lorddaedra  staff   1279 16 окт 02:56 activate.csh
-rw-r--r--   1 lorddaedra  staff   2415 16 окт 02:56 activate.fish
-rwxr-xr-x   1 lorddaedra  staff    305  4 сен 14:49 django-admin
-rwxr-xr-x   1 lorddaedra  staff    164  4 сен 14:49 django-admin.py
-rwxr-xr-x   1 lorddaedra  staff    272 12 окт 16:43 easy_install
-rwxr-xr-x   1 lorddaedra  staff    272 12 окт 16:43 easy_install-3.4
-rwxr-xr-x   1 lorddaedra  staff   3670  2 окт 04:34 jwt
-rw-r--r--   1 lorddaedra  staff   2369 15 окт 13:56 pilconvert.py
-rw-r--r--   1 lorddaedra  staff  15636 15 окт 13:56 pildriver.py
-rw-r--r--   1 lorddaedra  staff   2614 15 окт 13:56 pilfile.py
-rw-r--r--   1 lorddaedra  staff   1060 15 окт 13:56 pilfont.py
-rw-r--r--   1 lorddaedra  staff   2415 15 окт 13:56 pilprint.py
-rwxr-xr-x   1 lorddaedra  staff    244 17 июн 23:46 pip
-rwxr-xr-x   1 lorddaedra  staff    244 17 июн 23:46 pip3
-rwxr-xr-x   1 lorddaedra  staff    244 17 июн 23:46 pip3.4
lrwxr-xr-x   1 lorddaedra  staff      9 17 июн 23:46 python -> python3.4
lrwxr-xr-x   1 lorddaedra  staff      9 17 июн 23:46 python3 -> python3.4
lrwxr-xr-x   1 lorddaedra  staff     53 17 июн 23:46 python3.4 -> /Users/lorddaedra/.pyenv/versions/3.4.1/bin/python3.4
-rwxr-xr-x   1 lorddaedra  staff    331 15 окт 13:56 raven
-rwxr-xr-x   1 lorddaedra  staff    633  6 окт 17:56 rst2html.py
-rwxr-xr-x   1 lorddaedra  staff    830  6 окт 17:56 rst2latex.py
-rwxr-xr-x   1 lorddaedra  staff    639  6 окт 17:56 rst2man.py
-rwxr-xr-x   1 lorddaedra  staff    803  6 окт 17:56 rst2odt.py
-rwxr-xr-x   1 lorddaedra  staff   1737  6 окт 17:56 rst2odt_prepstyles.py
-rwxr-xr-x   1 lorddaedra  staff    640  6 окт 17:56 rst2pseudoxml.py
-rwxr-xr-x   1 lorddaedra  staff    676  6 окт 17:56 rst2s5.py
-rwxr-xr-x   1 lorddaedra  staff    825  6 окт 17:56 rst2xetex.py
-rwxr-xr-x   1 lorddaedra  staff    641  6 окт 17:56 rst2xml.py
-rwxr-xr-x   1 lorddaedra  staff    709  6 окт 17:56 rstpep2html.py
-rwxr-xr-x   1 lorddaedra  staff   3891 12 окт 16:43 sqlformat
(byvshie) Alexanders-MacBook-Air:~ lorddaedra$

Can not deactivate virtual environment

I activate an virtualenv called study3 with the command pyenv activate study3. In this time, I have my python in the version of study3

Then I want to deactivate study3 and I input the command pyenv deactivate study3 or pyenv deactivate study3 and I get no result. I still have the version of study3.

Is there anything I did wrong or do I have some misunderstanding about the command?

Pyenv virtualenv installing in different location than the PYENV_ROOT path

I've already installed few virtualenvs (those virtualenvs are listed down when i check pyenv virtualenvs in /usr/local/opt/pyenv/versions)

In zshrc i've added these lines

export PYENV_ROOT="/usr/local/opt/pyenv"
eval "$(pyenv init -)"
eval "$(pyenv virtualenv-init -)"

$PYENV_ROOT is available in shell

echo $PYENV_ROOT : /usr/local/opt/pyenv

But if i try to install new pyenv version and using it creating a new virtualenv, the installation goes in different folder (i guess default) ~/.pyenv

Because of that my new virtualenv is not available (in pyenv virtualenvs, hence i can't use it)

  1. What is the issue? Why it's installing in other location than the pyenv_root?
  2. Is it possible to tell pyenv virtualenv that virtualenvs are in 2 locations? (adding the current location?) or how to solve this?

pyenv virtualenv not matching ucs4 installation

I'm trying to install a virtual environment that uses UCS-4 encoding. I've installed my base python installation with:

PYTHON_CONFIGURE_OPTS="--enable-unicode=ucs4" pyenv install 2.7.5
mv $PYENV_ROOT/versions/2.7.5 $PYENV_ROOT/versions/2.7.5_ucs4
pyenv install 2.7.5
pyenv global 2.7.5_ucs4

If I run python -c "import sys; print sys.maxunicode", it prints 1114111, indicating that UCS-4 is installed. When I then run:

pyenv virtualenv vEnv
pyenv local vEnv
python -c "import sys; print sys.maxunicode"

it prints out 65535, indicating UCS-2 is installed.

Should I be doing something differently?

Add 'VIRTUAL_ENV' environment variable for jedi to add site-packages into PATH

Hi there,

I found there is no 'VIRTUAL_ENV' environment variable which is used by jedi library
https://github.com/davidhalter/jedi/blob/master/jedi/evaluate/sys_path.py#L13

Could you prefer to add this one ? For example, I have a virtualenv in ~/.pyenv/versions/web/. The VIRTUAL_ENV will be ~/.pyenv/versions/web/, so that ~/.pyenv/versions/web/lib/python2.7/site-packages will be added into sys.path when jedi loads. Jedi will autocomplete the packages in that folder.

My environment : pyenv-virtualenv + jedi-vim

pyenv-virtualenv initialisation failing.

When running $ eval "$(pyenv virtualenv-init -)", I always get this error message:

Failed to deactivate virtualenv.

Perhaps pyenv-virtualenv has not been loaded into your shell properly.
Please restart current shell and try again.

For some reason, I can still use it on the same shell I installed it in, but not any other shell. How do I load up pyenv-virtualenv properly? Note: I Installed it using Homebrew.

I just realised I have issues with my virtualenv:

$ python
-bash: /Users/ncopty/.pyenv/versions/finprod/bin/python: No such file or directory
$ ~/.virtualenvs/finprod/bin/python
Python 2.7.2 (default, Jul  2 2014, 14:30:17) 
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.34.4)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

Which one is the correct one and why do I have two?

pydoc3 link to existing Python install

Not sure if I did something wrong, but seems that the venv environment lacks of the pydoc link to the installed pyenv Python version, i.e, it's calling the system default instance from within the virtualenv, instead of the installed pyenv version it depends on.

Happened with pyenv + virtualenv of 3.4.2 python version:

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.