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.
