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
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.
In most systems, python2 or python3 command/soft-link would almost
always exist. In such cases, we don't need to invoke `python` to
detect the version. This should speed things up a bit as well.
Docker For Mac has broken support for `docker-compose`.
Since `docker compose` is a drop in replacement and it Just Works™, this PR converts `docker-compose` to `docker compose`
While previusly configurable, it was inconsistent with other
configuration options and it was missing configurability of in memory /
on disc history size.
Signed-off-by: Shea690901 <ginny690901@hotmail.de>
Two additional sets of paths are now added to the default list of well
known paths: '$HOME/{bin,sbin}' and '/opt/{homebrew,local}/{bin,sbin}'.
- '$HOME/{bin,sbin}': Most users have custom scripts in '$HOME/bin'
anyway, we might as well honor those. '$HOME/sbin' is not really common,
but we can keep it for consistency.
- '/opt/{homebrew,local}/{bin,sbin}': With Homebrew changing default
installation location in macOS on Apple Silicon which will eventually
become ubiquitous, we have a good reason to add these paths by default.
While at it, we also honor MacPorts installation.
In all cases, we add them _iff_ the paths actually exist, not otherwise.
This has the side effect of a newly installed program not available
immediately in the '$path' in a mint fresh system (because of the fact
that '/opt/{homebrew,local}/{bin,sbin}' won't exist initially) until the
shell is reloaded. But that's a minor inconvenience to keep the '$path'
from getting unnecessarily bloated.
For performance reasons, we prefer detecting Homebrew prefix internally
instead of the more idiomatic form `brew --repository`.
We attempt looking up $HOMEBREW_REPOSITORY first (in case `brew shellenv`
has been sourced-in earlier). Else, we look it up by resolving absolute
path of $HOMEBREW_REPOSITORY.
This should work for most standard (and officially documented) Homebrew
installations.
For performance reasons, we prefer detecting Homebrew prefix internally
instead of the more idiomatic form `brew --prefix`.
We attempt looking up $HOMEBREW_PREFIX or $HOMEBREW_REPOSITORY first (in
case `brew shellenv` has been sourced-in earlier). Else, we look it up
by resolving absolute path of $HOMEBREW_REPOSITORY. $HOMEBREW_PREFIX is
same as $HOMEBREW_REPOSITORY except when Homebrew is installed in
'/usr/local' ($HOMEBREW_REPOSITORY == '/usr/local/Homebrew'). This is
usually the case for Intel Macs.
This should work for most standard (and officially documented) Homebrew
installations.
For implementation details in Homebrew,
see: 2a850e02d8/bin/brew (L62-L70)
Co-authored-by: mattmc3 <mattmc3@gmail.com>
If conda is not in the list of requirements, the scripts exit too early in case pyenv is not installed and the module is configured with:
zstyle ':prezto:module:python' skip-virtualenvwrapper-init 'on'
zstyle ':prezto:module:python' conda-init 'on'
Tested on Amazon EC2 Linux for Deeplearning AMI 47.0 and MacOS 11.4
Changes:
- Simplify nodenv and nvm initialization
- Check for availability of `nodenv` or `nvm` function instead of command
- Unset local variables outside condition block
Unset `curl_prefix` outside condition block so that it is always
cleared. Also, avoid `brew --prefix <foo>` since it is triggering ruby
in fallback flow when `<foo>` is not present.
Also, apply minor formatting tweaks.
Changes:
- Honor `$RBENV_ROOT` or `RVM_DIR` if set but, no need to set it
explicitly if not set. Instead, let the respective initialization
scripts take care of that.
- Reverse `rbenv` vs `rvm` selection order, preferring `rbenv` instead.
- Check for availability of `rbenv` or `rvm` function instead of command
to validate requirements. In a properly configured and initialized
shell, `rbenv` or `rvm` will be available as function.
- Adhere to more idiomatic Zsh operation and minimize redundant syntaxes.
For additional rationale, see: https://github.com/rbenv/rbenv/wiki/Why-rbenv%3F
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.
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.
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`.
