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`.
Indrajit Raychaudhuri
mattmc3
Julio Batista Silva
Roman Perepelitsa
huyz
Jeff Widman
Michael Hoang
Thomas Blaschke
Shea690901
Ilkin Bayramli
Ben
Eugen Blattner
Jim Boulter
Aaron Kanter
Zach Birenbaum
David Crook
Andrew Kvalheim