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`.
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.
xenua
Eugen Blattner