Zinit can install from so-called packages – GitHub repositories holding
package.json file with the Zinit 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.
The motivation for adding such functionality was:
Zinit is a flexible plugin manager, however, users often feel overwhelmed by its configuration.
It has multiple package-manager -like features, such as:
- it can run
- automatically provide shims (i.e.: forwarder scripts) for the binaries,
$PATHto expose the binaries, and more.
- it can run
In general, Zinit has many hooks which allow surprising things, however their content often evolves to a gradually better and better one and it's hard to keep track of the current version of them.
So a solution appeared: why not publish a package at GitHub with the plugin configurations (i.e.: ice-mod lists) stored in a file?
This way, instead of the following command used to install
zinit 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 \ junegunn/fzf
you only need:
zinit 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 Zinit 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
zinit update fzf – it'll cause the
project to refresh and rebuild, like with a "normal" package manager such as
apt-get. However, it'll actually 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
pack'' ice :)
Pros Of Using Zinit Package For Regular Software Installations#
Using Zinit to install software where one could use a regular package manager has several advantages:
Pro: The Zinit packages typically use the URLs to the official and latest distributions of the software (like 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 Zinit ice-mods, e.g.:
zinit 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 from release-tarball, or from 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 Patch-Dl annex features.
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 to, 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 an additional ice:
then to have the
README converted into a man page by the
processor or other via an
atclone'' ice, as the tool doesn't have any official
The home for the packages is Zsh-Packages
GitHub organization. You can find the available packages there, which as of
- asciidoctor – the AsciiDoc converter, installed as a Gem locally in the plugin directory with use of the Bin-Gem-Node annex,
- doctoc – the TOC (table of contents)
generator for Markdown documents, installed as a Node package locally in the
plugin directory with use of the
- ecs-cli – the Amazon ECS command line tool, downloaded directly from the URL (or from the URL for OS X – automatically selected),
- firefox-dev – Firefox Developer
Edition, downloaded from the
(or from the
for OS X; the OS X installation only downloads the
dmgimage, so it is'nt yet complete),
- fzf – the fuzzy-finder, installed from source (from a tarball or Git) or from the GitHub-releases binary,
- ls_colors – the
trapd00r/LS_COLORS color definitions
ogham/exaand Zshell's completion.
Adding Your Own Package#
Contact the author to have the repository at Zsh-Packages organization.
package.json– I suggest grabbing the one for
doctocand doing a few substitutions like
your-projectand then simply filling the
defaultprofile in the
zinit-icesobject – it's obvious how to do this.
The project name in the
package.jsonshould start with
zsh-. The prefix will be skipped when specifying it with Zinit.
Commit and push.