If khal is packaged for your OS/distribution, using your system’s standard package manager is probably the easiest way to install khal. khal has been packaged for, among others: Arch Linux (stable and development versions), Debian, Fedora, FreeBSD, Guix, and pkgsrc (or see repology for a more complete list).
If a package isn’t available (or it is outdated) you need to fall back to one of the methods mentioned below.
Install via Python’s Package Managers¶
Since khal is written in python, you can use one of the package managers available to install python packages, e.g. pip.
You can install the latest released version of khal by executing:
pip install khal
or the latest development version by executing:
pip install git+git://github.com/pimutils/khal.git
This should also take care of installing all required dependencies. If in doubt, do not use sudo pip install but install pip install khal –user. Especially if using the –user flag, khal might be installed to ~/.local/bin. So if your shell cannot find khal, you might want to check there and add that folder to your $PATH.
Otherwise, you can always download the latest release from pypi and execute:
python setup.py install
pip install .
in the unpacked distribution folder.
Since version 0.10, khal only supports python 3.6+. If you have python 2 and 3 installed in parallel you might need to use pip3 instead of pip and python3 instead of python. In case your operating system cannot deal with python 2 and 3 packages concurrently, we suggest installing khal in a virtualenv (e.g. by using virtualenvwrapper or with the help of pipsi) and then starting khal from that virtual environment.
khal is written in python and can run on Python 3.6+. It requires a Python
sqlite3 support enabled (which is usually the case).
If you are installing python via pip or from source, be aware that since khal indirectly depends on lxml you need to either install it via your system’s package manager or have python’s libxml2’s and libxslt1’s headers (included in a separate “development package” on some distributions) installed.
If your packages are generated by running
setup.py install or some similar
mechanism, you’ll end up with very slow entry points (eg:
Package managers should use the files included in
bin as a replacement for
The root cause of the issue is really how python’s setuptools generates these and outside of the scope of this project
If your packages are generated using python wheels, this should not be an issue
(much like it won’t be an issue for users installing via