The motivation for adding packages functionality:
ZI is a flexible and feature-rich plugin manager, however, users often feel overwhelmed by its configuration.
It has multiple package-manager like features, such as:
- get the plugin's Git repository OR release-package URL,
- get the list of the recommended ices for the plugin,
- there can be multiple lists of ices,
- the ice lists are stored in profiles; there's at least one profile, default,
- the ices can be selectively overridden.
- automatically provide so-called shims (i.e.: forwarder scripts) for the binaries,
$PATHto expose the binaries,
- it can run
In general, ZI has many hooks which allow surprising things, however, their content often evolves to a gradually better one and it's hard to keep track of all the current versions.
The bin-gem-node annex is recommended, otherwise, some packages will fail to install due to missing functionality.
They allow the installation of any Gem(s) or Node module(s) locally in a newly created plugin directory. For example:
zi pack param='GEM -> rails' for any-gem
zi pack param='MOD -> doctoc' for any-node
If the installation is used in the
.zshrc file then use
id-as'…', then ZI knows that the package is already installed.
The Unicode arrow is allowed in ZI syntax as in the example below.
zi id-as=jekyll pack param='GEM → jekyll' for any-gem
The binaries will be exposed without altering the PATH via shims. Shims are correctly removed when deleting a plugin with
zi delete … The so-called packages are GitHub repositories holding a
package.json file with the meta-data in them. This way you don't have to (but still can) specify ices, which might be handy when the ice-mod list is long and complex.
This way, instead of the following command used to install
zi lucid as=program pick="$ZPFX/bin/(fzf|fzf-tmux)" \
atclone="cp shell/completion.zsh _fzf_completion; \
cp bin/(fzf|fzf-tmux) $ZPFX/bin" \
make="PREFIX=$ZPFX install" for \
you only need:
zi pack for fzf
to get the complete setup of the fuzzy finder, including:
- the completion,
- the additional executable script
The installation is real, package-manager -like, because you don't need to invoke ZI anymore once installed to use
fzf (that's because
fzf is just a binary program and not e.g.: a shell function).
You can also update the package with
zi update fzf – it'll cause the project to refresh and rebuild, like with a "normal" package manager such as
However, it'll be more like to
emerge from Gentoo, because the installation will be from the source… unless… the user will pick up a binary installation by profile argument specified in the
Pros of using the ZI package for regular software installations
Using ZI to install software where one could use a regular package manager has several advantages:
Pro: The ZI packages typically use the URLs to the official and latest distributions of the software (e.g.: the ecs-cli package, which uses the URL:
https://amazon-ecs-cli.s3.amazonaws.com/ecs-cli-linux-amd64-latestwhen installing on Linux).
Pro: You can influence the installation easily by specifying ZI ice-mods, e.g.:
zi pack=bgn atclone="cp fzy.1 $ZPFX/man/man1" for fzy
to install also the man page for the
fzyfuzzy finder (this omission in the package will be fixed soon).
Pro: The installation is much more flexible than a normal package manager. Example available degrees of freedom:
- to install from Git or release-tarball, or a binary-release file,
- to install via shims or via extending
$PATH, or by copying to
- to download files and apply patches to the source by using the
Pro: The installations are located in the user home directory, which doesn't require root access. Also, for Gems and Node modules, they are installed in their plugin directory, which can have advantages (e.g.: isolation allowing e.g: easy removal by
rm -rf …).
Con: You're somewhat "on your own", with no support from any package maintainer.
Thus, summing up 1. with 4., it might be nice/convenient too, for example, have the latest ECS CLI binary installed in the home directory, without using root access and always the latest, and – summing up with 2. and 3. – to, for example, have always the latest
README downloaded by additional ice:
dl'https://raw.githubusercontent.com/aws/amazon-ecs-cli/master/README.md' (and then to have the
README converted into a man page by the
remark Markdown processor or other via an
atclone'' ice, as the tool doesn't have any official man page).
Adding your package
package.json– I suggest grabbing the one for
doctocand doing a few substitutions like doctoc →
your-projectand then simply filling the
defaultprofile in the
zi-icesobject – it is same as passing ices to
zi ice …but in JSON.
The project name in the
package.jsonshould start with
zsh-. The prefix will be skipped when specifying it with ZI.
Commit and push.