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>
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`.
Placing `--no-use` inside the quoted string results in source
attempting to load a file which literally ends with ` --no-use`
instead of passing --no-use as an argument.
Modern `git` can use `submodule` option `update` instead of `foreach`
to achieve approximately similar outcome.
To allows call without assuming that all submodules will have default
branch as `master`, the preferred approach would be to call
`git submodule update --remote --recursive` after registering the
correct branch for submodule in `.gitmodules`:
```
git config -f .gitmodules submodule.<path>.branch <branch>
```
For more discussion, see: https://stackoverflow.com/a/33835815
Signed-off-by: Indrajit Raychaudhuri <irc@indrajit.com>
Changes:
- Prefer longer form of git switch for better clarity.
- Move `-S` (`--gpg-sign`) in all the alias definitions to the end to
allow custom keyid.
- Simplify operations in helper functions git native calls.
- Apply minor reformatting and rearranging.
Move `grunt` and `gulp` to separate completion definitions wrapping
`grunt --completion=zsh` and `gulp --completion=zsh` respectively.
Since the completions are loaded lazily on demand, they avoid the
performance overhead during Zsh initialization.
Additionally, remove `npm` completion since it is already bundled with
Zsh for quite a while.
Changes:
- nodenv and nvm now honors (and prioritizes) `$XDG_CONFIG_HOME` over
`$HOME` to lookup local nodenv/nvm installation.
- Make `nvm` loading lazy (via `--no-use` argument).
- Remove redundant NODENV_ROOT or NVM_DIR, respective script already
set them up.
- Adhere to more idiomatic Zsh operation and minimize external command
usage (like `sed`).
Set `LS_COLORS` if not already available so that it is available as
standard style `list-colors`.
This needs to be explicitly set in completion module to ensure that the
variable is available even if 'utility' module is not loaded earlier.
Laura Hausmann
