alpha
/
prezto
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '5ac930d96b'
${ noResults }
prezto/modules/python/init.zsh

179 lines
6.0 KiB
Raw Normal View History Unescape

Added or edited file headers.
13 years ago
#
# Enables local Python package installation.
#
# Authors:
# Sorin Ionescu <sorin.ionescu@gmail.com>
Source virtualenvwrapper in python module
13 years ago
# Sebastian Wiesner <lunaryorn@googlemail.com>
Added conda virtualenv support to python module. (#1505) * Added conda virtualenv support to python module * Added instructions for Python module options to README Thanks to @egpbos for the original feature and @ickc for fixing the merge conflicts.
7 years ago
# Patrick Bos <egpbos@gmail.com>
python: Optimize completion for loading lazily on demand Move `pip` to separate completion definition delegating to pip to do all the completion work. Since the completion is loaded lazily on-demand, it avoids the performance overhead during Zsh initialization. Implementation note: The helper function `_pip_completion` implementation is based on the official pip completion function (which can be generated with `pip completion --zsh`) adhering to the newer compsys style. See: 'man zshcompsys' for more details.
4 years ago
# Indrajit Raychaudhuri <irc@indrajit.com>
Added or edited file headers.
13 years ago
#
Set `EXTENDED_GLOB` in the python module This is needed to find python. It is often already set because a user has the directory or completion module loaded before this, but that's not always true. See extensive debugging / further explanation here: https://github.com/sorin-ionescu/prezto/issues/1949 This does not fully resolve that issue, as there's another enhancement that I'll put up as a separate PR.
2 years ago
#
# Options
#
setopt EXTENDED_GLOB
python: Reformat and apply visual cleanup Changes: - Fallback to `virtualenvwrapper` without `pyenv` wrapper if `python` is available in path, regardless of whether `brew` is available. - Look up for availability of `python2` and `python3`, not just `python`. - Check for existence of path before adding to global `$path` array. - Adhere to more idiomatic Zsh operation and minimize redundant syntaxes. - Prefer looking up `$functions` for fully initialized `pyenv`.
4 years ago
# Load dependencies.
Fix missing dependency on helper module for helpers added in #1793 (#1811) PR #1793 introduced helper functions for OS detection in some modules. These helpers require a module dependency on the 'helper' module.
5 years ago
pmodload 'helper'
python: Update pyenv initialization flow per pyenv 2.0 In pyenv 2.0 onwards, it is not enough anymore to initialize pyenv in shell by just calling `pyenv init -`. We also need to update `path` to include pyenv shims by calling `pyenv init --path`. Also, honor `$PYENV_ROOT` if set but, no need to set it explicitly if not set. Instead, let the initialization script take care of that.
4 years ago
# Load manually installed or package manager installed pyenv into the shell
# session.
if [[ -s "${local_pyenv::=${PYENV_ROOT:-$HOME/.pyenv}/bin/pyenv}" ]] \
|| (( $+commands[pyenv] )); then
[Fix #297] Check for pythonz before returning
12 years ago
python: Update pyenv initialization flow per pyenv 2.0 In pyenv 2.0 onwards, it is not enough anymore to initialize pyenv in shell by just calling `pyenv init -`. We also need to update `path` to include pyenv shims by calling `pyenv init --path`. Also, honor `$PYENV_ROOT` if set but, no need to set it explicitly if not set. Instead, let the initialization script take care of that.
4 years ago
# Ensure manually installed pyenv is added to path when present.
[[ -s $local_pyenv ]] && path=($local_pyenv:h $path)
# pyenv 2+ requires shims to be added to path before being initialized.
autoload -Uz is-at-least
if is-at-least 2 ${"$(pyenv --version 2>&1)"[(w)2]}; then
eval "$(pyenv init --path zsh)"
fi
eval "$(pyenv init - zsh)"
[Fix #202] Load modules all or nothing
12 years ago
Added Python plugin, moved pip completion into it.
13 years ago
# Prepend PEP 370 per user site packages directory, which defaults to
Rename "Mac OS X" to "macOS" in comments This only changes references in text for human consumption. It leaves out renaming paths because that can cause breaking changes. Related issue https://github.com/sorin-ionescu/prezto/issues/1449.
7 years ago
# ~/Library/Python on macOS and ~/.local elsewhere, to PATH. The
Support $PYTHONUSERBASE per PEP 370 Signed-off-by: Sorin Ionescu <sorin.ionescu@gmail.com>
11 years ago
# path can be overridden using PYTHONUSERBASE.
Added Python plugin, moved pip completion into it.
13 years ago
else
Support $PYTHONUSERBASE per PEP 370 Signed-off-by: Sorin Ionescu <sorin.ionescu@gmail.com>
11 years ago
if [[ -n "$PYTHONUSERBASE" ]]; then
python: Reformat and apply visual cleanup Changes: - Fallback to `virtualenvwrapper` without `pyenv` wrapper if `python` is available in path, regardless of whether `brew` is available. - Look up for availability of `python2` and `python3`, not just `python`. - Check for existence of path before adding to global `$path` array. - Adhere to more idiomatic Zsh operation and minimize redundant syntaxes. - Prefer looking up `$functions` for fully initialized `pyenv`.
4 years ago
path=($PYTHONUSERBASE/bin(N) $path)
feat(helper): add os-type helper functions Add the following functions: - is-darwin - is-linux - is-bsd - is-cygwin And apply them everywhere I found code doing that what these functions do.
5 years ago
elif is-darwin; then
Replace pythonz with pyenv Depending on Python to manage Python is silly.
11 years ago
path=($HOME/Library/Python/*/bin(N) $path)
else
# This is subject to change.
python: Reformat and apply visual cleanup Changes: - Fallback to `virtualenvwrapper` without `pyenv` wrapper if `python` is available in path, regardless of whether `brew` is available. - Look up for availability of `python2` and `python3`, not just `python`. - Check for existence of path before adding to global `$path` array. - Adhere to more idiomatic Zsh operation and minimize redundant syntaxes. - Prefer looking up `$functions` for fully initialized `pyenv`.
4 years ago
path=($HOME/.local/bin(N) $path)
Replace pythonz with pyenv Depending on Python to manage Python is silly.
11 years ago
fi
fi
python: Update pyenv initialization flow per pyenv 2.0 In pyenv 2.0 onwards, it is not enough anymore to initialize pyenv in shell by just calling `pyenv init -`. We also need to update `path` to include pyenv shims by calling `pyenv init --path`. Also, honor `$PYENV_ROOT` if set but, no need to set it explicitly if not set. Instead, let the initialization script take care of that.
4 years ago
unset local_pyenv
Replace pythonz with pyenv Depending on Python to manage Python is silly.
11 years ago
# Return if requirements are not found.
python: Expand Python command pattern per convention Use `(i)python[0-9.]#` as subscript for commands associative array, following the convention [1] of detection python more exhaustively. [1] https://github.com/zsh-users/zsh/blob/858b8de3d70fe76a3637c281bc2c8e3a6d961a2c/Completion/Unix/Command/_python#L1
2 years ago
if (( ! $+commands[(i)python[0-9.]#] && ! $+functions[pyenv] && ! $+commands[conda] )); then
Replace pythonz with pyenv Depending on Python to manage Python is silly.
11 years ago
return 1
Added Python plugin, moved pip completion into it.
13 years ago
fi
Python virtualenv auto workon cwd hook (#1300) * Command to activate virtualenvs on changing directory Enables automatic activation of a virtualenv when jumping into a directory This is done by looking in the current directory for a file or directory named `.venv`. If it's not found in the current directory its parents will also be examined. `.venv` can be either: 1. A file containing the name of a virtualenv found in $WORKON_HOME 2. A directory containing bin/activate (meaning that the directory is assumed to be a virtualenv.) If $WORKON_HOME is set it is assumed that virtualenvwrapper is installed and the `workon` command will be issued.
8 years ago
function _python-workon-cwd {
python: Reformat and apply visual cleanup Changes: - Fallback to `virtualenvwrapper` without `pyenv` wrapper if `python` is available in path, regardless of whether `brew` is available. - Look up for availability of `python2` and `python3`, not just `python`. - Check for existence of path before adding to global `$path` array. - Adhere to more idiomatic Zsh operation and minimize redundant syntaxes. - Prefer looking up `$functions` for fully initialized `pyenv`.
4 years ago
# Check if this is a Git repo.
local GIT_REPO_ROOT="$(git rev-parse --show-toplevel 2> /dev/null)"
# Get absolute path, resolving symlinks.
local PROJECT_ROOT="$PWD:A"
Python virtualenv auto workon cwd hook (#1300) * Command to activate virtualenvs on changing directory Enables automatic activation of a virtualenv when jumping into a directory This is done by looking in the current directory for a file or directory named `.venv`. If it's not found in the current directory its parents will also be examined. `.venv` can be either: 1. A file containing the name of a virtualenv found in $WORKON_HOME 2. A directory containing bin/activate (meaning that the directory is assumed to be a virtualenv.) If $WORKON_HOME is set it is assumed that virtualenvwrapper is installed and the `workon` command will be issued.
8 years ago
while [[ "$PROJECT_ROOT" != "/" && ! -e "$PROJECT_ROOT/.venv" \
python: Reformat and apply visual cleanup Changes: - Fallback to `virtualenvwrapper` without `pyenv` wrapper if `python` is available in path, regardless of whether `brew` is available. - Look up for availability of `python2` and `python3`, not just `python`. - Check for existence of path before adding to global `$path` array. - Adhere to more idiomatic Zsh operation and minimize redundant syntaxes. - Prefer looking up `$functions` for fully initialized `pyenv`.
4 years ago
&& ! -d "$PROJECT_ROOT/.git" && "$PROJECT_ROOT" != "$GIT_REPO_ROOT" ]]; do
PROJECT_ROOT="$PROJECT_ROOT:h"
Python virtualenv auto workon cwd hook (#1300) * Command to activate virtualenvs on changing directory Enables automatic activation of a virtualenv when jumping into a directory This is done by looking in the current directory for a file or directory named `.venv`. If it's not found in the current directory its parents will also be examined. `.venv` can be either: 1. A file containing the name of a virtualenv found in $WORKON_HOME 2. A directory containing bin/activate (meaning that the directory is assumed to be a virtualenv.) If $WORKON_HOME is set it is assumed that virtualenvwrapper is installed and the `workon` command will be issued.
8 years ago
done
python: Reformat and apply visual cleanup Changes: - Fallback to `virtualenvwrapper` without `pyenv` wrapper if `python` is available in path, regardless of whether `brew` is available. - Look up for availability of `python2` and `python3`, not just `python`. - Check for existence of path before adding to global `$path` array. - Adhere to more idiomatic Zsh operation and minimize redundant syntaxes. - Prefer looking up `$functions` for fully initialized `pyenv`.
4 years ago
if [[ $PROJECT_ROOT == "/" ]]; then
Python virtualenv auto workon cwd hook (#1300) * Command to activate virtualenvs on changing directory Enables automatic activation of a virtualenv when jumping into a directory This is done by looking in the current directory for a file or directory named `.venv`. If it's not found in the current directory its parents will also be examined. `.venv` can be either: 1. A file containing the name of a virtualenv found in $WORKON_HOME 2. A directory containing bin/activate (meaning that the directory is assumed to be a virtualenv.) If $WORKON_HOME is set it is assumed that virtualenvwrapper is installed and the `workon` command will be issued.
8 years ago
PROJECT_ROOT="."
fi
python: Reformat and apply visual cleanup Changes: - Fallback to `virtualenvwrapper` without `pyenv` wrapper if `python` is available in path, regardless of whether `brew` is available. - Look up for availability of `python2` and `python3`, not just `python`. - Check for existence of path before adding to global `$path` array. - Adhere to more idiomatic Zsh operation and minimize redundant syntaxes. - Prefer looking up `$functions` for fully initialized `pyenv`.
4 years ago
# Check for virtualenv name override.
Python virtualenv auto workon cwd hook (#1300) * Command to activate virtualenvs on changing directory Enables automatic activation of a virtualenv when jumping into a directory This is done by looking in the current directory for a file or directory named `.venv`. If it's not found in the current directory its parents will also be examined. `.venv` can be either: 1. A file containing the name of a virtualenv found in $WORKON_HOME 2. A directory containing bin/activate (meaning that the directory is assumed to be a virtualenv.) If $WORKON_HOME is set it is assumed that virtualenvwrapper is installed and the `workon` command will be issued.
8 years ago
local ENV_NAME=""
if [[ -f "$PROJECT_ROOT/.venv" ]]; then
python: Reformat and apply visual cleanup Changes: - Fallback to `virtualenvwrapper` without `pyenv` wrapper if `python` is available in path, regardless of whether `brew` is available. - Look up for availability of `python2` and `python3`, not just `python`. - Check for existence of path before adding to global `$path` array. - Adhere to more idiomatic Zsh operation and minimize redundant syntaxes. - Prefer looking up `$functions` for fully initialized `pyenv`.
4 years ago
ENV_NAME="$(<$PROJECT_ROOT/.venv)"
python: respect PYENV_ROOT if already set Fixes #1578
6 years ago
elif [[ -f "$PROJECT_ROOT/.venv/bin/activate" ]]; then
Python virtualenv auto workon cwd hook (#1300) * Command to activate virtualenvs on changing directory Enables automatic activation of a virtualenv when jumping into a directory This is done by looking in the current directory for a file or directory named `.venv`. If it's not found in the current directory its parents will also be examined. `.venv` can be either: 1. A file containing the name of a virtualenv found in $WORKON_HOME 2. A directory containing bin/activate (meaning that the directory is assumed to be a virtualenv.) If $WORKON_HOME is set it is assumed that virtualenvwrapper is installed and the `workon` command will be issued.
8 years ago
ENV_NAME="$PROJECT_ROOT/.venv"
python: Reformat and apply visual cleanup Changes: - Fallback to `virtualenvwrapper` without `pyenv` wrapper if `python` is available in path, regardless of whether `brew` is available. - Look up for availability of `python2` and `python3`, not just `python`. - Check for existence of path before adding to global `$path` array. - Adhere to more idiomatic Zsh operation and minimize redundant syntaxes. - Prefer looking up `$functions` for fully initialized `pyenv`.
4 years ago
elif [[ $PROJECT_ROOT != "." ]]; then
ENV_NAME="$PROJECT_ROOT:t"
Python virtualenv auto workon cwd hook (#1300) * Command to activate virtualenvs on changing directory Enables automatic activation of a virtualenv when jumping into a directory This is done by looking in the current directory for a file or directory named `.venv`. If it's not found in the current directory its parents will also be examined. `.venv` can be either: 1. A file containing the name of a virtualenv found in $WORKON_HOME 2. A directory containing bin/activate (meaning that the directory is assumed to be a virtualenv.) If $WORKON_HOME is set it is assumed that virtualenvwrapper is installed and the `workon` command will be issued.
8 years ago
fi
if [[ -n $CD_VIRTUAL_ENV && "$ENV_NAME" != "$CD_VIRTUAL_ENV" ]]; then
python: Reformat and apply visual cleanup Changes: - Fallback to `virtualenvwrapper` without `pyenv` wrapper if `python` is available in path, regardless of whether `brew` is available. - Look up for availability of `python2` and `python3`, not just `python`. - Check for existence of path before adding to global `$path` array. - Adhere to more idiomatic Zsh operation and minimize redundant syntaxes. - Prefer looking up `$functions` for fully initialized `pyenv`.
4 years ago
# We've just left the repo, deactivate the environment.
# Note: this only happens if the virtualenv was activated automatically.
Python virtualenv auto workon cwd hook (#1300) * Command to activate virtualenvs on changing directory Enables automatic activation of a virtualenv when jumping into a directory This is done by looking in the current directory for a file or directory named `.venv`. If it's not found in the current directory its parents will also be examined. `.venv` can be either: 1. A file containing the name of a virtualenv found in $WORKON_HOME 2. A directory containing bin/activate (meaning that the directory is assumed to be a virtualenv.) If $WORKON_HOME is set it is assumed that virtualenvwrapper is installed and the `workon` command will be issued.
8 years ago
deactivate && unset CD_VIRTUAL_ENV
fi
python: Reformat and apply visual cleanup Changes: - Fallback to `virtualenvwrapper` without `pyenv` wrapper if `python` is available in path, regardless of whether `brew` is available. - Look up for availability of `python2` and `python3`, not just `python`. - Check for existence of path before adding to global `$path` array. - Adhere to more idiomatic Zsh operation and minimize redundant syntaxes. - Prefer looking up `$functions` for fully initialized `pyenv`.
4 years ago
if [[ $ENV_NAME != "" ]]; then
# Activate the environment only if it is not already active.
Python virtualenv auto workon cwd hook (#1300) * Command to activate virtualenvs on changing directory Enables automatic activation of a virtualenv when jumping into a directory This is done by looking in the current directory for a file or directory named `.venv`. If it's not found in the current directory its parents will also be examined. `.venv` can be either: 1. A file containing the name of a virtualenv found in $WORKON_HOME 2. A directory containing bin/activate (meaning that the directory is assumed to be a virtualenv.) If $WORKON_HOME is set it is assumed that virtualenvwrapper is installed and the `workon` command will be issued.
8 years ago
if [[ "$VIRTUAL_ENV" != "$WORKON_HOME/$ENV_NAME" ]]; then
Add check for empty WORKON_HOME (#1861) When $WORKON_HOME is not set and $ENV_NAME is equal to $PROJECT_ROOT/.venv which contains bin/activate then the code wrongly assumes workon is available. It should execute the second branch to source bin/activate.
4 years ago
if [[ -n "$WORKON_HOME" && -e "$WORKON_HOME/$ENV_NAME/bin/activate" ]]; then
Python virtualenv auto workon cwd hook (#1300) * Command to activate virtualenvs on changing directory Enables automatic activation of a virtualenv when jumping into a directory This is done by looking in the current directory for a file or directory named `.venv`. If it's not found in the current directory its parents will also be examined. `.venv` can be either: 1. A file containing the name of a virtualenv found in $WORKON_HOME 2. A directory containing bin/activate (meaning that the directory is assumed to be a virtualenv.) If $WORKON_HOME is set it is assumed that virtualenvwrapper is installed and the `workon` command will be issued.
8 years ago
workon "$ENV_NAME" && export CD_VIRTUAL_ENV="$ENV_NAME"
elif [[ -e "$ENV_NAME/bin/activate" ]]; then
source $ENV_NAME/bin/activate && export CD_VIRTUAL_ENV="$ENV_NAME"
fi
fi
fi
}
python: Reformat and apply visual cleanup Changes: - Fallback to `virtualenvwrapper` without `pyenv` wrapper if `python` is available in path, regardless of whether `brew` is available. - Look up for availability of `python2` and `python3`, not just `python`. - Check for existence of path before adding to global `$path` array. - Adhere to more idiomatic Zsh operation and minimize redundant syntaxes. - Prefer looking up `$functions` for fully initialized `pyenv`.
4 years ago
# Load auto workon cwd hook.
if zstyle -t ':prezto:module:python:virtualenv' auto-switch; then
# Auto workon when changing directory.
python: autoload add-zsh-hook when needed (#1549) Fixes #1550
7 years ago
autoload -Uz add-zsh-hook
Move virtualenv auto-switch cwd hook optional loader out from inside unrelated if statement (#1338)
7 years ago
add-zsh-hook chpwd _python-workon-cwd
fi
[python] Improve and document `virtualenvwrapper` initialization flow Changes: * Simplify zstyle name `skip-virtualenvwrapper-init` to `initialize` avoiding double negation in name * Always perform `eval (pyenv virtualenv-init -)` at initialization * Prefer `virtualenvwrapper_lazy` over `virtualenvwrapper` when available * Honor `VIRTUALENVWRAPPER_VIRTUALENV` if it is defined. * Document about `VIRTUALENVWRAPPER_PYTHON` and `VIRTUALENVWRAPPER_VIRTUALENV` (this would be particularly important in macOS after recent homebrew update) * Add additional documentation for `initialize` in _README.md_ and _zpreztorc_ * Add aliases `py2`, `py3` as shortcut for `python2`, `python3` respectively
7 years ago
# Load virtualenvwrapper into the shell session, if pre-requisites are met
# and unless explicitly requested not to
python: Reformat and apply visual cleanup Changes: - Fallback to `virtualenvwrapper` without `pyenv` wrapper if `python` is available in path, regardless of whether `brew` is available. - Look up for availability of `python2` and `python3`, not just `python`. - Check for existence of path before adding to global `$path` array. - Adhere to more idiomatic Zsh operation and minimize redundant syntaxes. - Prefer looking up `$functions` for fully initialized `pyenv`.
4 years ago
if (( $+VIRTUALENVWRAPPER_VIRTUALENV || $+commands[virtualenv] )) \
&& zstyle -T ':prezto:module:python:virtualenv' initialize ; then
Set the virtualenvwrapper $WORKON_HOME variable
12 years ago
# Set the directory where virtual environments are stored.
Add support for skipping VIRTUALENVWRAPPER init in modules/python (#598) * Support skip-virtualenvwrapper-init zstyle in python module to avoid auto-sourcing of virtualenvwrapper.sh * Don't overwrite the WORKON_HOME env var if the user has already set it
8 years ago
export WORKON_HOME="${WORKON_HOME:-$HOME/.virtualenvs}"
Set the virtualenvwrapper $WORKON_HOME variable
12 years ago
python: use pure's magic value for VIRTUAL_ENV_DISABLE_PROMPT Fixes #1627
6 years ago
# Disable the virtualenv prompt. Note that we use the magic value used by the
# pure prompt because there's some additional logic in that prompt which tries
# to figure out if a user set this variable and disable the python portion of
# that prompt based on it which is the exact opposite of what we want to do.
export VIRTUAL_ENV_DISABLE_PROMPT=12
Set the virtualenvwrapper $WORKON_HOME variable
12 years ago
[python] Refine pyenv based virtualenv management Now that pyenv plugins availability is detected by directly probing 'pyenv', we need to rely on the same mechanism consistently. Further, we perform available pyenv plugin scan with native zsh techniques instead of relying on external commands.
7 years ago
# Create a sorted array of available virtualenv related 'pyenv' commands to
# look for plugins of interest. Scanning shell '$path' isn't enough as they
# can exist in 'pyenv' synthesized paths (e.g., '~/.pyenv/plugins') instead.
local -a pyenv_plugins
Support `virtualenvwrapper` with / without `pyenv` `virtualenv-init` or `virtualenvwrapper` plugins The desired logic is: For the `pyenv` plugins `virtualenv-init` and `virtualenvwrapper`: 1. If either plugin is present, activate it 2. If `virtualenvwrapper` plugin is not present, then [fallback to standard `virtualenvwrapper`](https://github.com/sorin-ionescu/prezto/pull/1414#issuecomment-320306421). 3. If `virtualenvwrapper` plugin is present, then [don't fallback to standard `virtualenvwrapper`, regardless of whether `virtualenv-init` is present](https://github.com/sorin-ionescu/prezto/pull/1981#issue-1123766676). Previously, if the `virtualenv` command was present but `pyenv` was missing, then the fallback wouldn't be hit. This bug was introduced by https://github.com/sorin-ionescu/prezto/pull/1981/ which ensured that the `pyenv` `virtualenvwrapper` plugin was activated if present, regardless of the presence of the `virtualenv-init` plugin. As an optimization, the check for the `pyenv` plugins are skipped if `pyenv` itself isn't found. Since we only want to fallback if the `pyenv` `virtualenvwrapper` plugin is missing, but that's buried within the `pyenv` logic and we also need to handle when `pyenv` itself is missing, this switches to using a flag variable. I also renamed the `virtualenv_sources` var to `virtualenvwrapper_sources` as `virtualenv` is distinct from `virtualenvwrapper`, so using one name for a var that is really about the other is confusing. Looking at `git blame`, there's a _lot_ of prior art here around trying to support all the permutations of `pyenv` and various plugins: * https://github.com/sorin-ionescu/prezto/issues/1413 * https://github.com/sorin-ionescu/prezto/pull/1414 * https://github.com/sorin-ionescu/prezto/pull/1433 * https://github.com/sorin-ionescu/prezto/pull/1434 So we need to be extremely careful to continue to support all these permutations. Fix https://github.com/sorin-ionescu/prezto/issues/2022
2 years ago
local pyenv_virtualenvwrapper_plugin_found
[python] Refine pyenv based virtualenv management Now that pyenv plugins availability is detected by directly probing 'pyenv', we need to rely on the same mechanism consistently. Further, we perform available pyenv plugin scan with native zsh techniques instead of relying on external commands.
7 years ago
if (( $+commands[pyenv] )); then
python: Reformat and apply visual cleanup Changes: - Fallback to `virtualenvwrapper` without `pyenv` wrapper if `python` is available in path, regardless of whether `brew` is available. - Look up for availability of `python2` and `python3`, not just `python`. - Check for existence of path before adding to global `$path` array. - Adhere to more idiomatic Zsh operation and minimize redundant syntaxes. - Prefer looking up `$functions` for fully initialized `pyenv`.
4 years ago
pyenv_plugins=(${(@oM)${(f)"$(pyenv commands --no-sh 2> /dev/null)"}:#virtualenv*})
[python] Refine pyenv based virtualenv management Now that pyenv plugins availability is detected by directly probing 'pyenv', we need to rely on the same mechanism consistently. Further, we perform available pyenv plugin scan with native zsh techniques instead of relying on external commands.
7 years ago
Support `virtualenvwrapper` with / without `pyenv` `virtualenv-init` or `virtualenvwrapper` plugins The desired logic is: For the `pyenv` plugins `virtualenv-init` and `virtualenvwrapper`: 1. If either plugin is present, activate it 2. If `virtualenvwrapper` plugin is not present, then [fallback to standard `virtualenvwrapper`](https://github.com/sorin-ionescu/prezto/pull/1414#issuecomment-320306421). 3. If `virtualenvwrapper` plugin is present, then [don't fallback to standard `virtualenvwrapper`, regardless of whether `virtualenv-init` is present](https://github.com/sorin-ionescu/prezto/pull/1981#issue-1123766676). Previously, if the `virtualenv` command was present but `pyenv` was missing, then the fallback wouldn't be hit. This bug was introduced by https://github.com/sorin-ionescu/prezto/pull/1981/ which ensured that the `pyenv` `virtualenvwrapper` plugin was activated if present, regardless of the presence of the `virtualenv-init` plugin. As an optimization, the check for the `pyenv` plugins are skipped if `pyenv` itself isn't found. Since we only want to fallback if the `pyenv` `virtualenvwrapper` plugin is missing, but that's buried within the `pyenv` logic and we also need to handle when `pyenv` itself is missing, this switches to using a flag variable. I also renamed the `virtualenv_sources` var to `virtualenvwrapper_sources` as `virtualenv` is distinct from `virtualenvwrapper`, so using one name for a var that is really about the other is confusing. Looking at `git blame`, there's a _lot_ of prior art here around trying to support all the permutations of `pyenv` and various plugins: * https://github.com/sorin-ionescu/prezto/issues/1413 * https://github.com/sorin-ionescu/prezto/pull/1414 * https://github.com/sorin-ionescu/prezto/pull/1433 * https://github.com/sorin-ionescu/prezto/pull/1434 So we need to be extremely careful to continue to support all these permutations. Fix https://github.com/sorin-ionescu/prezto/issues/2022
2 years ago
# Optionally activate 'virtualenv-init' plugin when available.
if (( $pyenv_plugins[(i)virtualenv-init] <= $#pyenv_plugins )); then
eval "$(pyenv virtualenv-init - zsh)"
fi
[python] Refine pyenv based virtualenv management Now that pyenv plugins availability is detected by directly probing 'pyenv', we need to rely on the same mechanism consistently. Further, we perform available pyenv plugin scan with native zsh techniques instead of relying on external commands.
7 years ago
Support `virtualenvwrapper` with / without `pyenv` `virtualenv-init` or `virtualenvwrapper` plugins The desired logic is: For the `pyenv` plugins `virtualenv-init` and `virtualenvwrapper`: 1. If either plugin is present, activate it 2. If `virtualenvwrapper` plugin is not present, then [fallback to standard `virtualenvwrapper`](https://github.com/sorin-ionescu/prezto/pull/1414#issuecomment-320306421). 3. If `virtualenvwrapper` plugin is present, then [don't fallback to standard `virtualenvwrapper`, regardless of whether `virtualenv-init` is present](https://github.com/sorin-ionescu/prezto/pull/1981#issue-1123766676). Previously, if the `virtualenv` command was present but `pyenv` was missing, then the fallback wouldn't be hit. This bug was introduced by https://github.com/sorin-ionescu/prezto/pull/1981/ which ensured that the `pyenv` `virtualenvwrapper` plugin was activated if present, regardless of the presence of the `virtualenv-init` plugin. As an optimization, the check for the `pyenv` plugins are skipped if `pyenv` itself isn't found. Since we only want to fallback if the `pyenv` `virtualenvwrapper` plugin is missing, but that's buried within the `pyenv` logic and we also need to handle when `pyenv` itself is missing, this switches to using a flag variable. I also renamed the `virtualenv_sources` var to `virtualenvwrapper_sources` as `virtualenv` is distinct from `virtualenvwrapper`, so using one name for a var that is really about the other is confusing. Looking at `git blame`, there's a _lot_ of prior art here around trying to support all the permutations of `pyenv` and various plugins: * https://github.com/sorin-ionescu/prezto/issues/1413 * https://github.com/sorin-ionescu/prezto/pull/1414 * https://github.com/sorin-ionescu/prezto/pull/1433 * https://github.com/sorin-ionescu/prezto/pull/1434 So we need to be extremely careful to continue to support all these permutations. Fix https://github.com/sorin-ionescu/prezto/issues/2022
2 years ago
# Optionally activate 'virtualenvwrapper' plugin when available.
if (( $pyenv_plugins[(i)virtualenvwrapper(_lazy|)] <= $#pyenv_plugins )); then
pyenv "$pyenv_plugins[(R)virtualenvwrapper(_lazy|)]"
pyenv_virtualenvwrapper_plugin_found="true"
fi
unset pyenv_plugins
Fix crash on open caused by incorrect conditional in python module
3 years ago
fi
[python] Ensure availability of virtualenvwrapper file before sourcing it
7 years ago
Support `virtualenvwrapper` with / without `pyenv` `virtualenv-init` or `virtualenvwrapper` plugins The desired logic is: For the `pyenv` plugins `virtualenv-init` and `virtualenvwrapper`: 1. If either plugin is present, activate it 2. If `virtualenvwrapper` plugin is not present, then [fallback to standard `virtualenvwrapper`](https://github.com/sorin-ionescu/prezto/pull/1414#issuecomment-320306421). 3. If `virtualenvwrapper` plugin is present, then [don't fallback to standard `virtualenvwrapper`, regardless of whether `virtualenv-init` is present](https://github.com/sorin-ionescu/prezto/pull/1981#issue-1123766676). Previously, if the `virtualenv` command was present but `pyenv` was missing, then the fallback wouldn't be hit. This bug was introduced by https://github.com/sorin-ionescu/prezto/pull/1981/ which ensured that the `pyenv` `virtualenvwrapper` plugin was activated if present, regardless of the presence of the `virtualenv-init` plugin. As an optimization, the check for the `pyenv` plugins are skipped if `pyenv` itself isn't found. Since we only want to fallback if the `pyenv` `virtualenvwrapper` plugin is missing, but that's buried within the `pyenv` logic and we also need to handle when `pyenv` itself is missing, this switches to using a flag variable. I also renamed the `virtualenv_sources` var to `virtualenvwrapper_sources` as `virtualenv` is distinct from `virtualenvwrapper`, so using one name for a var that is really about the other is confusing. Looking at `git blame`, there's a _lot_ of prior art here around trying to support all the permutations of `pyenv` and various plugins: * https://github.com/sorin-ionescu/prezto/issues/1413 * https://github.com/sorin-ionescu/prezto/pull/1414 * https://github.com/sorin-ionescu/prezto/pull/1433 * https://github.com/sorin-ionescu/prezto/pull/1434 So we need to be extremely careful to continue to support all these permutations. Fix https://github.com/sorin-ionescu/prezto/issues/2022
2 years ago
if [[ $pyenv_virtualenvwrapper_plugin_found != "true" ]]; then
# Fallback to standard 'virtualenvwrapper' if 'python' is available in '$path'.
python: Expand Python command pattern per convention Use `(i)python[0-9.]#` as subscript for commands associative array, following the convention [1] of detection python more exhaustively. [1] https://github.com/zsh-users/zsh/blob/858b8de3d70fe76a3637c281bc2c8e3a6d961a2c/Completion/Unix/Command/_python#L1
2 years ago
if (( ! $+VIRTUALENVWRAPPER_PYTHON )) && (( $+commands[(i)python[0-9.]#] )); then
VIRTUALENVWRAPPER_PYTHON=$commands[(i)python[0-9.]#]
Support `virtualenvwrapper` with / without `pyenv` `virtualenv-init` or `virtualenvwrapper` plugins The desired logic is: For the `pyenv` plugins `virtualenv-init` and `virtualenvwrapper`: 1. If either plugin is present, activate it 2. If `virtualenvwrapper` plugin is not present, then [fallback to standard `virtualenvwrapper`](https://github.com/sorin-ionescu/prezto/pull/1414#issuecomment-320306421). 3. If `virtualenvwrapper` plugin is present, then [don't fallback to standard `virtualenvwrapper`, regardless of whether `virtualenv-init` is present](https://github.com/sorin-ionescu/prezto/pull/1981#issue-1123766676). Previously, if the `virtualenv` command was present but `pyenv` was missing, then the fallback wouldn't be hit. This bug was introduced by https://github.com/sorin-ionescu/prezto/pull/1981/ which ensured that the `pyenv` `virtualenvwrapper` plugin was activated if present, regardless of the presence of the `virtualenv-init` plugin. As an optimization, the check for the `pyenv` plugins are skipped if `pyenv` itself isn't found. Since we only want to fallback if the `pyenv` `virtualenvwrapper` plugin is missing, but that's buried within the `pyenv` logic and we also need to handle when `pyenv` itself is missing, this switches to using a flag variable. I also renamed the `virtualenv_sources` var to `virtualenvwrapper_sources` as `virtualenv` is distinct from `virtualenvwrapper`, so using one name for a var that is really about the other is confusing. Looking at `git blame`, there's a _lot_ of prior art here around trying to support all the permutations of `pyenv` and various plugins: * https://github.com/sorin-ionescu/prezto/issues/1413 * https://github.com/sorin-ionescu/prezto/pull/1414 * https://github.com/sorin-ionescu/prezto/pull/1433 * https://github.com/sorin-ionescu/prezto/pull/1434 So we need to be extremely careful to continue to support all these permutations. Fix https://github.com/sorin-ionescu/prezto/issues/2022
2 years ago
fi
virtualenvwrapper_sources=(
${(@Ov)commands[(I)virtualenvwrapper(_lazy|).sh]}
/usr/share/virtualenvwrapper/virtualenvwrapper(_lazy|).sh(OnN)
)
if (( $#virtualenvwrapper_sources )); then
source "$virtualenvwrapper_sources[1]"
fi
unset virtualenvwrapper_sources
Add better support for pyenv virtualenvs
8 years ago
fi
[python] Refine pyenv based virtualenv management Now that pyenv plugins availability is detected by directly probing 'pyenv', we need to rely on the same mechanism consistently. Further, we perform available pyenv plugin scan with native zsh techniques instead of relying on external commands.
7 years ago
Support `virtualenvwrapper` with / without `pyenv` `virtualenv-init` or `virtualenvwrapper` plugins The desired logic is: For the `pyenv` plugins `virtualenv-init` and `virtualenvwrapper`: 1. If either plugin is present, activate it 2. If `virtualenvwrapper` plugin is not present, then [fallback to standard `virtualenvwrapper`](https://github.com/sorin-ionescu/prezto/pull/1414#issuecomment-320306421). 3. If `virtualenvwrapper` plugin is present, then [don't fallback to standard `virtualenvwrapper`, regardless of whether `virtualenv-init` is present](https://github.com/sorin-ionescu/prezto/pull/1981#issue-1123766676). Previously, if the `virtualenv` command was present but `pyenv` was missing, then the fallback wouldn't be hit. This bug was introduced by https://github.com/sorin-ionescu/prezto/pull/1981/ which ensured that the `pyenv` `virtualenvwrapper` plugin was activated if present, regardless of the presence of the `virtualenv-init` plugin. As an optimization, the check for the `pyenv` plugins are skipped if `pyenv` itself isn't found. Since we only want to fallback if the `pyenv` `virtualenvwrapper` plugin is missing, but that's buried within the `pyenv` logic and we also need to handle when `pyenv` itself is missing, this switches to using a flag variable. I also renamed the `virtualenv_sources` var to `virtualenvwrapper_sources` as `virtualenv` is distinct from `virtualenvwrapper`, so using one name for a var that is really about the other is confusing. Looking at `git blame`, there's a _lot_ of prior art here around trying to support all the permutations of `pyenv` and various plugins: * https://github.com/sorin-ionescu/prezto/issues/1413 * https://github.com/sorin-ionescu/prezto/pull/1414 * https://github.com/sorin-ionescu/prezto/pull/1433 * https://github.com/sorin-ionescu/prezto/pull/1434 So we need to be extremely careful to continue to support all these permutations. Fix https://github.com/sorin-ionescu/prezto/issues/2022
2 years ago
unset pyenv_virtualenvwrapper_plugin_found
Source virtualenvwrapper in python module
13 years ago
fi
python: Reformat and apply visual cleanup Changes: - Fallback to `virtualenvwrapper` without `pyenv` wrapper if `python` is available in path, regardless of whether `brew` is available. - Look up for availability of `python2` and `python3`, not just `python`. - Check for existence of path before adding to global `$path` array. - Adhere to more idiomatic Zsh operation and minimize redundant syntaxes. - Prefer looking up `$functions` for fully initialized `pyenv`.
4 years ago
# Load conda into the shell session, if requested.
Added conda virtualenv support to python module. (#1505) * Added conda virtualenv support to python module * Added instructions for Python module options to README Thanks to @egpbos for the original feature and @ickc for fixing the merge conflicts.
7 years ago
zstyle -T ':prezto:module:python' conda-init
if (( $? && $+commands[conda] )); then
if (( $(conda ..changeps1) )); then
echo "To make sure Conda doesn't change your prompt (should do that in the prompt module) run:\n conda config --set changeps1 false"
# TODO:
# We could just run this ourselves. In an exit hook
# (add zsh-hook zshexit [(anonymous) function]) we could then set it back
# to the way it was before we changed it. However, I'm not sure if this is
# exception safe, so left it like this for now.
fi
fi
Alias py to python
12 years ago
#
# Aliases
#
Add zstyle to skip aliases for additional modules
2 years ago
if ! zstyle -t ':prezto:module:python:alias' skip; then
alias py='python'
alias py2='python2'
alias py3='python3'
fi