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.
`get` alias now supports `aria2c` via optional `zstyle`.
To configure `aria2c` to be used for `get`, use:
zstyle -s ':prezto:module:utility:download' helper 'aria2c'
Note that we still fall back to `curl` when the desired download helper
isn't available.
Skip additional call to `grep` and use Zsh native mechanism to detect
GNU version of `du`.
Further, Remove redundant `function` clause as per Prezto convention.
Use `git` fallback (if present) even when color is off and `wdiff` is
not present.
Further, remove redundant `function` clause as per Prezto convention.
Zsh and Prezto files don't always reside in `~/`. Instead, they have
a more spec compliant location (`${ZDOTDIR:-$HOME}/`). Make them
unambiguous in the documentation. Likewise, for `$GNUPGHOME`.
Further, add instruction for optionally setting up Prezto in
`$XDG_CONFIG_HOME`.
While at this, also add clarification on relative ordering of some of
the modules, apply more formatting tweaks and doc improvements.
Detect `ls` provided by GNU Core Utilities upfront before applying
the relevant settings and aliases.
The revised logic takes the following aspects into consideration:
- `is-callable 'dircolors'` is not a sufficient test for verifying if
the `ls` in scope is _also_ provided by GNU Core Utilities. `ls` can
continue to be the one provided by BSD Core Utilities because of its
precedence in `$path`.
- The `ls` in scope anyway can be either GNU Utils provided or BSD Utils
provided depending on either `$path` precedence, soft link (via
`ln -s`), or wrapper function (via 'gnu-utility' module).
- So instead of '_guessing_' the possible one, just detect if it is from
GNU Utils and apply the relevant settings and aliases.
- Note that GNU prefixed `ls` (`gls`) is intentionally not honored in
this case to avoid possible conflict/shadowing with other `gls`
callable (can happen if 'git' module is used, for example).
Besides, honoring `gls` would imply we honor other commands (like
`mv`, `rm` etc.) to be consistent. We have a module 'gnu-utils'
dedicated for that after all.
