dcarrillo/prezto
1
0
Fork 0
mirror of https://github.com/dcarrillo/prezto.git synced 2024-11-16 02:41:13 +00:00
Code Issues Releases Wiki Activity
8ee9d1bbfe
prezto/modules/python/init.zsh

179 lines
6.0 KiB
Bash
Raw Normal View History

Added or edited file headers.
2012-02-01 04:37:51 +00:00
#
# Enables local Python package installation.
#
# Authors:
# Sorin Ionescu <sorin.ionescu@gmail.com>
Source virtualenvwrapper in python module
2012-04-12 11:06:37 +00:00
# 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.
2017-11-13 00:20:52 +00:00
# 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.
2020-12-01 05:55:27 +00:00
# Indrajit Raychaudhuri <irc@indrajit.com>
Added or edited file headers.
2012-02-01 04:37:51 +00:00
#
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.
2022-10-25 22:49:51 +00:00
#
# 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`.
2020-12-01 04:05:27 +00:00
# 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.
2020-03-29 19:49:35 +00:00
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.
2021-05-24 22:31:17 +00:00
# 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
2012-09-25 16:57:57 +00:00
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.
2021-05-24 22:31:17 +00:00
# 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
2012-07-23 19:00:44 +00:00
Added Python plugin, moved pip completion into it.
2011-08-27 23:09:06 +00:00
# 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.
2018-04-16 22:51:57 +00:00
# ~/Library/Python on macOS and ~/.local elsewhere, to PATH. The
Support $PYTHONUSERBASE per PEP 370 Signed-off-by: Sorin Ionescu <sorin.ionescu@gmail.com>
2014-03-17 17:31:21 +00:00
# path can be overridden using PYTHONUSERBASE.
Added Python plugin, moved pip completion into it.
2011-08-27 23:09:06 +00:00
else
Support $PYTHONUSERBASE per PEP 370 Signed-off-by: Sorin Ionescu <sorin.ionescu@gmail.com>
2014-03-17 17:31:21 +00:00
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`.
2020-12-01 04:05:27 +00:00
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.
2020-02-13 08:56:29 +00:00
elif is-darwin; then
Replace pythonz with pyenv Depending on Python to manage Python is silly.
2013-08-20 12:21:17 +00:00
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`.
2020-12-01 04:05:27 +00:00
path=($HOME/.local/bin(N) $path)
Replace pythonz with pyenv Depending on Python to manage Python is silly.
2013-08-20 12:21:17 +00:00
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.
2021-05-24 22:31:17 +00:00
unset local_pyenv
Replace pythonz with pyenv Depending on Python to manage Python is silly.
2013-08-20 12:21:17 +00:00
# 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
2023-04-27 02:11:09 +00:00
if (( ! $+commands[(i)python[0-9.]#] && ! $+functions[pyenv] && ! $+commands[conda] )); then
Replace pythonz with pyenv Depending on Python to manage Python is silly.
2013-08-20 12:21:17 +00:00
return 1
Added Python plugin, moved pip completion into it.
2011-08-27 23:09:06 +00:00
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.
2017-05-31 00:26:18 +00:00
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`.
2020-12-01 04:05:27 +00:00
# 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.
2017-05-31 00:26:18 +00:00
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`.
2020-12-01 04:05:27 +00:00
&& ! -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.
2017-05-31 00:26:18 +00:00
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`.
2020-12-01 04:05:27 +00:00
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.
2017-05-31 00:26:18 +00:00
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`.
2020-12-01 04:05:27 +00:00
# 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.
2017-05-31 00:26:18 +00:00
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`.
2020-12-01 04:05:27 +00:00
ENV_NAME="$(<$PROJECT_ROOT/.venv)"
python: respect PYENV_ROOT if already set Fixes #1578
2018-09-28 21:24:25 +00:00
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.
2017-05-31 00:26:18 +00:00
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`.
2020-12-01 04:05:27 +00:00
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.
2017-05-31 00:26:18 +00:00
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`.
2020-12-01 04:05:27 +00:00
# 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.
2017-05-31 00:26:18 +00:00
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`.
2020-12-01 04:05:27 +00:00
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.
2017-05-31 00:26:18 +00:00
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.
2020-07-27 19:49:40 +00:00
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.
2017-05-31 00:26:18 +00:00
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`.
2020-12-01 04:05:27 +00:00
# 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
2018-02-23 21:39:45 +00:00
autoload -Uz add-zsh-hook
Move virtualenv auto-switch cwd hook optional loader out from inside unrelated if statement (#1338)
2017-06-21 19:30:57 +00:00
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
2017-07-25 00:34:11 +00:00
# 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`.
2020-12-01 04:05:27 +00:00
if (( $+VIRTUALENVWRAPPER_VIRTUALENV || $+commands[virtualenv] )) \
&& zstyle -T ':prezto:module:python:virtualenv' initialize ; then
Set the virtualenvwrapper $WORKON_HOME variable
2012-09-03 14:53:19 +00:00
# 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
2017-04-04 06:06:02 +00:00
export WORKON_HOME="${WORKON_HOME:-$HOME/.virtualenvs}"
Set the virtualenvwrapper $WORKON_HOME variable
2012-09-03 14:53:19 +00:00
python: use pure's magic value for VIRTUAL_ENV_DISABLE_PROMPT Fixes #1627
2018-09-28 21:04:20 +00:00
# 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
2012-09-03 14:53:19 +00:00
[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.
2017-08-18 03:53:25 +00:00
# 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
2022-10-26 04:24:51 +00:00
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.
2017-08-18 03:53:25 +00:00
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`.
2020-12-01 04:05:27 +00:00
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.
2017-08-18 03:53:25 +00:00
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
2022-10-26 04:24:51 +00:00
# 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.
2017-08-18 03:53:25 +00:00
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
2022-10-26 04:24:51 +00:00
# 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
2022-02-04 03:08:36 +00:00
fi
[python] Ensure availability of virtualenvwrapper file before sourcing it
2017-08-18 12:55:34 +00:00
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
2022-10-26 04:24:51 +00:00
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
2023-04-27 02:11:09 +00:00
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
2022-10-26 04:24:51 +00:00
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
2017-04-18 10:14:22 +00:00
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.
2017-08-18 03:53:25 +00:00
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
2022-10-26 04:24:51 +00:00
unset pyenv_virtualenvwrapper_plugin_found
Source virtualenvwrapper in python module
2012-04-12 11:06:37 +00:00
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`.
2020-12-01 04:05:27 +00:00
# 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.
2017-11-13 00:20:52 +00:00
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
2012-08-15 12:00:08 +00:00
#
# Aliases
#
Add zstyle to skip aliases for additional modules
2023-04-13 02:02:41 +00:00
if ! zstyle -t ':prezto:module:python:alias' skip; then
alias py='python'
alias py2='python2'
alias py3='python3'
fi
Reference in New Issue Copy Permalink