2012-02-01 04:37:51 +00:00
|
|
|
#
|
|
|
|
# Enables local Python package installation.
|
|
|
|
#
|
|
|
|
# Authors:
|
|
|
|
# Sorin Ionescu <sorin.ionescu@gmail.com>
|
2012-04-12 11:06:37 +00:00
|
|
|
# Sebastian Wiesner <lunaryorn@googlemail.com>
|
2017-11-13 00:20:52 +00:00
|
|
|
# Patrick Bos <egpbos@gmail.com>
|
2020-12-01 05:55:27 +00:00
|
|
|
# Indrajit Raychaudhuri <irc@indrajit.com>
|
2012-02-01 04:37:51 +00:00
|
|
|
#
|
|
|
|
|
2022-10-25 22:49:51 +00:00
|
|
|
#
|
|
|
|
# Options
|
|
|
|
#
|
|
|
|
|
|
|
|
setopt EXTENDED_GLOB
|
|
|
|
|
2020-12-01 04:05:27 +00:00
|
|
|
# Load dependencies.
|
2020-03-29 19:49:35 +00:00
|
|
|
pmodload 'helper'
|
|
|
|
|
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
|
2012-09-25 16:57:57 +00:00
|
|
|
|
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)
|
|
|
|
|
2023-10-05 18:45:56 +00:00
|
|
|
# Load pyenv into the shell session.
|
2021-05-24 22:31:17 +00:00
|
|
|
eval "$(pyenv init - zsh)"
|
2012-07-23 19:00:44 +00:00
|
|
|
|
2011-08-27 23:09:06 +00:00
|
|
|
# Prepend PEP 370 per user site packages directory, which defaults to
|
2018-04-16 22:51:57 +00:00
|
|
|
# ~/Library/Python on macOS and ~/.local elsewhere, to PATH. The
|
2014-03-17 17:31:21 +00:00
|
|
|
# path can be overridden using PYTHONUSERBASE.
|
2011-08-27 23:09:06 +00:00
|
|
|
else
|
2014-03-17 17:31:21 +00:00
|
|
|
if [[ -n "$PYTHONUSERBASE" ]]; then
|
2020-12-01 04:05:27 +00:00
|
|
|
path=($PYTHONUSERBASE/bin(N) $path)
|
2020-02-13 08:56:29 +00:00
|
|
|
elif is-darwin; then
|
2013-08-20 12:21:17 +00:00
|
|
|
path=($HOME/Library/Python/*/bin(N) $path)
|
|
|
|
else
|
|
|
|
# This is subject to change.
|
2020-12-01 04:05:27 +00:00
|
|
|
path=($HOME/.local/bin(N) $path)
|
2013-08-20 12:21:17 +00:00
|
|
|
fi
|
|
|
|
fi
|
|
|
|
|
2021-05-24 22:31:17 +00:00
|
|
|
unset local_pyenv
|
|
|
|
|
2013-08-20 12:21:17 +00:00
|
|
|
# Return if requirements are not found.
|
2023-04-27 02:11:09 +00:00
|
|
|
if (( ! $+commands[(i)python[0-9.]#] && ! $+functions[pyenv] && ! $+commands[conda] )); then
|
2013-08-20 12:21:17 +00:00
|
|
|
return 1
|
2011-08-27 23:09:06 +00:00
|
|
|
fi
|
|
|
|
|
2017-05-31 00:26:18 +00:00
|
|
|
function _python-workon-cwd {
|
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"
|
2017-05-31 00:26:18 +00:00
|
|
|
while [[ "$PROJECT_ROOT" != "/" && ! -e "$PROJECT_ROOT/.venv" \
|
2020-12-01 04:05:27 +00:00
|
|
|
&& ! -d "$PROJECT_ROOT/.git" && "$PROJECT_ROOT" != "$GIT_REPO_ROOT" ]]; do
|
|
|
|
PROJECT_ROOT="$PROJECT_ROOT:h"
|
2017-05-31 00:26:18 +00:00
|
|
|
done
|
2020-12-01 04:05:27 +00:00
|
|
|
if [[ $PROJECT_ROOT == "/" ]]; then
|
2017-05-31 00:26:18 +00:00
|
|
|
PROJECT_ROOT="."
|
|
|
|
fi
|
2020-12-01 04:05:27 +00:00
|
|
|
# Check for virtualenv name override.
|
2017-05-31 00:26:18 +00:00
|
|
|
local ENV_NAME=""
|
|
|
|
if [[ -f "$PROJECT_ROOT/.venv" ]]; then
|
2020-12-01 04:05:27 +00:00
|
|
|
ENV_NAME="$(<$PROJECT_ROOT/.venv)"
|
2018-09-28 21:24:25 +00:00
|
|
|
elif [[ -f "$PROJECT_ROOT/.venv/bin/activate" ]]; then
|
2017-05-31 00:26:18 +00:00
|
|
|
ENV_NAME="$PROJECT_ROOT/.venv"
|
2020-12-01 04:05:27 +00:00
|
|
|
elif [[ $PROJECT_ROOT != "." ]]; then
|
|
|
|
ENV_NAME="$PROJECT_ROOT:t"
|
2017-05-31 00:26:18 +00:00
|
|
|
fi
|
|
|
|
if [[ -n $CD_VIRTUAL_ENV && "$ENV_NAME" != "$CD_VIRTUAL_ENV" ]]; then
|
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.
|
2017-05-31 00:26:18 +00:00
|
|
|
deactivate && unset CD_VIRTUAL_ENV
|
|
|
|
fi
|
2020-12-01 04:05:27 +00:00
|
|
|
if [[ $ENV_NAME != "" ]]; then
|
|
|
|
# Activate the environment only if it is not already active.
|
2017-05-31 00:26:18 +00:00
|
|
|
if [[ "$VIRTUAL_ENV" != "$WORKON_HOME/$ENV_NAME" ]]; then
|
2020-07-27 19:49:40 +00:00
|
|
|
if [[ -n "$WORKON_HOME" && -e "$WORKON_HOME/$ENV_NAME/bin/activate" ]]; then
|
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
|
|
|
|
}
|
|
|
|
|
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.
|
2018-02-23 21:39:45 +00:00
|
|
|
autoload -Uz add-zsh-hook
|
2017-06-21 19:30:57 +00:00
|
|
|
add-zsh-hook chpwd _python-workon-cwd
|
|
|
|
fi
|
|
|
|
|
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
|
2020-12-01 04:05:27 +00:00
|
|
|
if (( $+VIRTUALENVWRAPPER_VIRTUALENV || $+commands[virtualenv] )) \
|
|
|
|
&& zstyle -T ':prezto:module:python:virtualenv' initialize ; then
|
2012-09-03 14:53:19 +00:00
|
|
|
# Set the directory where virtual environments are stored.
|
2017-04-04 06:06:02 +00:00
|
|
|
export WORKON_HOME="${WORKON_HOME:-$HOME/.virtualenvs}"
|
2012-09-03 14:53:19 +00:00
|
|
|
|
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
|
2012-09-03 14:53:19 +00:00
|
|
|
|
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
|
2017-08-18 03:53:25 +00:00
|
|
|
if (( $+commands[pyenv] )); then
|
2020-12-01 04:05:27 +00:00
|
|
|
pyenv_plugins=(${(@oM)${(f)"$(pyenv commands --no-sh 2> /dev/null)"}:#virtualenv*})
|
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
|
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
|
2022-02-04 03:08:36 +00:00
|
|
|
fi
|
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'.
|
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
|
2017-04-18 10:14:22 +00:00
|
|
|
fi
|
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
|
2012-04-12 11:06:37 +00:00
|
|
|
fi
|
|
|
|
|
2020-12-01 04:05:27 +00:00
|
|
|
# Load conda into the shell session, if requested.
|
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
|
|
|
|
|
2012-08-15 12:00:08 +00:00
|
|
|
#
|
|
|
|
# Aliases
|
|
|
|
#
|
|
|
|
|
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
|