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.
`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.
General purpose reformating and rewording in (a few places). This should
also make markdown linting happier.
Prefer back-ticks wherever useful and use `console` for code blocks to
be executed on terminal.
Also, update references links wherever possible (including update from
'http://' to 'https://').
Remove `--protect-decmpfs` by default since hfs-compression specific
changes have been marked by upstream as broken since 3.1.3 and there is
little likelihood of that changing.
As curl bundled with macOS does not include `_curl` definitions, one
way to make `_curl` available is to install curl from Homebrew.
However, since curl from Hombrew is _keg-only_, its function path needs
to be explicitly included.
Change default `HISTFILE` path from `~/.zhistory` to more conventional
`~/.zsh_history`. This aligns better with Debian variants, macOS and
Oh My Zsh.
This would provide an easier onboarding experience to users coming to
Prezto from standard (framework free) zsh or from Oh My Zsh.
For existing Prezto users, we attempt to automatically rename old
`HISTFILE` to new one iff the old one exists and the new one doesn't.
However, if both old and new `HISTFILE` exist and the old one is more
recent, we just alert the user about what changed with a suggested way
to accommodate the change.
I think this should have been removed as part of 0a07ba27a2.
Currently I'm seeing this warning after updating to `master`:
```
Couldn't read file /Users/jeffwidman/.zprezto/modules/prompt/functions/prompt_powerlevel9k_setup containing theme powerlevel9k.
```
`compinit -i` doesn't always change zcompdump, which means that the
`compinit -C` condition fails to run until the completions change.
When we `compinit -i`, we should touch the file too to solve this.
