JKL is a version manager for other command-line tools

  • By Ivan Fetch
  • Last update: Aug 25, 2022
  • Comments: 2

JKL - A Tool Version Manager

JKL is a version manager for other command-line tools. It installs tools quickly with minimal input, and helps you switch versions of tools while you work.

JKL is a public work in progress - not all functionality is complete and there are plenty of rough edges.

  • Install a new command-line tool from its Github release or direct download URL.
    • Target a specific version (v1.2.3), latest, or the latest partial version (v1.2 or v1).
    • Versions can match Github release tags with or without a leading v.
    • A Github asset is matched to your operating system and architecture.
    • It's ok if the tool is contained in a tar or zip archive.
  • JKL creates a "shim" to intercept the execution of the just-installed tool, so that whenyou attempt to run the tool JKL can determine which version to run.
    • Specify which version of a given tool to run via an an environment variable, configuration file, or your shell current directory.
    • Specifying latest runs the latest installed version.
    • Defaults can be set by configuration files in higher-level parent directories. Child configuration files can specify only a tool's version, with parent configuration files specifying where that tool can be downloaded.
  • Install multiple tools in parallel - useful when bootstrapping a new workstation or standard versions of tooling used by a project.

JKL Installation

This process is mostly incomplete as I experiment for the best user experience. The intent is:

  • Download a Github release or build JKL on your own if desired.
  • Put the jkl binary in your $PATH, ideally the same location where you would like JKL to create shims for JKL-managed tools.
  • Optionally override the directory where JKL manages tools that it installs. This defaults to ~/.jkl/installs
  • Use JKL to install your first tool by running jkl -i github:User/Repo (replacing User and Repo with a Github user and repository).

##Features Under Consideration

These are features or user experience that need more consideration.

  • JKL configuration files will specify the "provider" and desired version of a tool. The provider represents where / how to download the tool (github, URLTemplate, CurlBash).
    • A provider may not need to be specified in all config files. Config files can be read from parent directories to find a tool's provider. This could allow a project/environment to specify desired tool versions without needing to care about the provider.
  • A JKL setup / init command that uses JKL to manage itself.
  • A central "for all users" operating mode to support shared environments like jump-boxes:
    • Avoid each user needing to install their own copies of common tools.
    • Allow users to install new tools or versions not already present in a shared location.
    • Try hard to not become a full-fledged package manager. :)
  • Support additional features via "plugins" - such as:
    • Some tools will require post-install action, like managing a shell initialization file.
    • Some tools will have multiple binaries, like Go, Python or other runtimes.
    • Some logic may be required depending on architecture or to generate default configuration for a tool.
  • Use user-installed tools, instead of JKL-managed ones.
    • The user-installed tools would follow a configurable naming convention such as tool.x.y.z or tool-x.y.z.
    • The first binary found in the PATH matching the naming convention would be used.
  • A cleanup option that uninstalls versions of tools that aren't referenced in config files within a directory tree.
  • A nuke option that uninstalls everything JKL manages.
  • A bulk purge option to remove all tools from a particular provider, or Github user.




  • 1

    support `reshim` command

    Sometimes people like myself do silly things like try to make jkl manage itself (don't do that with the current version), and need to re-link/shim all of the apps installed. Unfortunately, while doing so, github's rate-limiting kicked in left me unable to use some tools until the symlinks are fixed. I could wait for github's rate-limiting to back down, or I could do it manually, but it'd be even better if jkl could just do its magic for me.

    Please add some kind of reshim-like command to make repairing a broken system much easier and quicker.

  • 2

    support `update` command

    I would like the ability to update the tool from within the tool (eg, jkl update). There are several Go projects to choose from which offer this functionality.