FAQ

Which Shells Does Hermit work with?¶

Hermit currently works with bash and zsh natively. fish is available via a workaround. But we would welcome contributions to support other shells.

`fish` support via `direnv`¶

Hermit does not currently support fish directly, but you can use direnv to achieve similar functionality.

Install direnv via your package manager.
Create $HOME/.direnvrc with the following content.
Create a project_dir/.envrc with the following content.
Use direnv allow to activate the environment (usually only needed on modification of .envrc)

`~/.direnvrc`¶

# shellcheck shell=bash

# derived from https://github.com/direnv/direnv/wiki/Python#virtualenvwrapper
layout_hermit() {
  local activate_hermit
  activate_hermit="$(\
    find . \
      -type f \
      -name 'activate-hermit' \
      -exec test -x {} \; \
      -print
  )"
  if [[ -n "$activate_hermit" ]];then
    # shellcheck source=/dev/null
    source "$activate_hermit"
  fi
}

`.envrc`¶

layout hermit

powerlevel10k support¶

If you would like powerlevel10k to support hermit, all that is needed is to add the following to your ~/.p10k.zsh

function prompt_hermit() {
  if [[ -n $HERMIT_ENV ]]; then
    p10k segment -t "${${HERMIT_ENV:t}//\%/%%} 🐚"  -f blue
  fi
}

Then you can add the hermit segment to any location. For example:

  typeset -g POWERLEVEL9K_LEFT_PROMPT_ELEMENTS=(
    # =========================[ Line #1 ]=========================
    os_icon                 # os identifier
    dir                     # current directory
    vcs                     # git status
    # =========================[ Line #2 ]=========================
    newline                 # \n
    hermit
    prompt_char             # prompt symbol
  )

Does Hermit Manage Libaries?¶

No, Hermit is deliberately not in the business of installing libraries. Hermit is designed to manage development tools only, not be a general purpose package manager. Consider Nix if you need this kind of functionality.

Is Python supported?¶

Yes!

Hermit sets PYTHONUSERBASE to ${HERMIT_ENV}/.hermit/python and adds ${PYTHONUSERBASE}/bin to the ${PATH} when in an activated environment. This results in packages installed within the environment being mostly (completely?) isolated similar to how virtualenv works.

Is Ruby supported?¶

Not yet. Hermit only supports static/relocatable binary packages and there are no recent Ruby versions compiled in this way. We would love contributions to support Ruby.

Why Doesn’t Hermit Have a Package for …?¶

There could be a number of reasons why a package isn’t present in Hermit.

The package may not be conducive to self-contained packaging (eg. Python).
The community might not have needed one (yet) - please contribute one!

Does the Hermit Project Build and Host its own Packages?¶

Yes and no. Mostly no, but some existing upstream binary packages require some level of pre-processing (eg. Python). These are hosted at cashapp/hermit-build.

How is Hermit different to …?¶

asdf¶

Hermit is probably most similar to asdf, but their goals differ. Hermit’s goal is to make isolated cross-platform tooling consistent, self-bootstrapping, and reproducible at the project level. asdf’s primary goal is to allow developers to install and switch between multiple versions of languages and tooling.

	Hermit	asdf	Compare
Packaging	HCL manifest	Shell script-based plugin API	Java in asdf / Java in Hermit.
Packages	Binary only.	Compile from source, binary, wrappers around pyenv, rbenv, etc.	Python in asdf / Python in Hermit

Limiting Hermit to installing only binary packages has pros and cons:

	Feature	Explanation
Pro	Faster	Binary packages don’t require compilation, just downloading and unpacking.
Con	Less choice	There are typically less relocatable/static binary packages available.
Con	Relocatable packages	Relocatable/static binary packages can be difficult to build.
Pro	Less fragile	Source installations fail frequently due to missing dependencies, missing tools, and so on.
Pro	Less requirements	Source installations generally require a functional compiler toolchain be already present on your system, such as GCC, clang, etc.

Bazel¶

While not really in the same space as Hermit, Bazel does provide build isolation and opt-in hermetic builds. However Bazel also:

Requires going all-in on Bazel as a build system, whereas Hermit is explicitly not a build system but rather integrates into existing toolchains.
Requires completely separate tooling, editor/IDE integration and so on.

Docker¶

Docker has a very large community and provides isolation, both of which are appealing. Unfortunately it has several shortcomings which in our view preclude it from use as a day to day development tooling system.

Filesystem mapping on OSX is very slow.
It does not support OSX binaries inside Docker (though see Docker-OSX).
Poor integration with host editors/IDEs (though there is some movement).

GoFish¶

GoFish’s package definitions are quite similar to Hermit’s, but GoFish itself:

Does not support multiple versions of the same package.
Requires root for system wide installation.
Does not support the concept of “environments”.

Homebrew¶

Homebrew is a full package build system but also:

Is a system wide package manager.
Is largely OSX specific.
Does not support concurrent installation of different versions of the same package well.

Nix¶

Nix is the package manager for an entire OS and thus provides vastly more functionality than Hermit, including a full package build system. This naturally also comes with a corresponding increase in complexity. Hermit is deliberately designed to be narrow in scope, limited to just installing existing packages.

FAQ