kitty-themes: about 170 ports, one symlink called theme.conf, and no releases

Only the original content is MIT, and each port keeps its citation

The licence paragraph is more careful than a badge. It says all original content of the repository is licensed with the MIT licence, and then adds that whenever possible the author of a theme is cited inside each theme configuration file together with its licence. It closes by asking to be contacted if you find your theme there and want a proper citation. That is the arrangement you would expect from a port collection: the plumbing is MIT, the colour schemes are other people's work with their own terms, and the attribution lives inside each file rather than in one list. The themes themselves are ported from a well known iTerm2 colour scheme repository, named and linked at the top of the README, so the upstream lineage is declared rather than implied.

The install writes one symlink, and that symlink is the switch

There are two ways to get the files and then a fixed three step finish. You either clone the whole repository shallow straight into the kitty configuration directory with a git clone at depth one, or you set a variable to a raw file address and fetch that single file into the themes directory with wget. After that the path is the same either way: change into the kitty configuration directory, create a symlink from a file named theme.conf to whichever theme file you picked, and add a line including that file to the kitty configuration itself.

cd ~/.config/kitty
ln -s ./kitty-themes/themes/Floraverse.conf ~/.config/kitty/theme.conf

Because the include names theme.conf rather than a theme, switching schemes means pointing the symlink somewhere else. The README's symlink example uses a file named Floraverse.conf and its single file example uses a different one, so the two routes in the instructions do not use the same example.

A conda package exists, and the repository has no releases

The second install route is a single command through the conda package manager, pulling a package named kitty-themes from the conda-forge channel. That matters more than it sounds, because the repository itself publishes no releases at all. There is no tag to pin, no changelog entry to read and no version number in the README, so the only named artefacts of this project are the files in the branch and whatever the conda channel last built from it. Two other details in the same area. The primary language recorded for the repository is Python even though what the repository contains is configuration files for a terminal, and there is a tools directory at the root that is where that Python tooling lives.

Previewing a theme needs either remote control or a second instance

The preview section offers two ways to see a scheme without changing your configuration, and it conditions the first on a setting. If you have enabled remote control in kitty, one command tells the running instance to adopt the colours of a theme file, which is the fastest way to cycle through schemes. If you have not enabled it, the alternative is to start a second kitty instance and point it at the theme file as an extra configuration include, in which case kitty reads both its normal configuration and the specified one. That second route is the one that works on a fresh install, and the README is explicit about the consequence: two configuration files are read at once, so anything in the theme file is applied on top of what you already have rather than replacing it.

The bonus script picks a random script from another repository and pipes it to bash

The last instruction in the preview section is the opposite of careful, and it is offered as a bonus. It sets a variable to the GitHub contents address of a colour script repository, fetches that address with curl, pipes the result through jq to build a path and a download address pair, filters with jq again, shuffles and takes one line, cuts out the address, downloads that file with wget and pipes the whole thing to bash. The README notes that it needs jq. So the documented bonus downloads an arbitrary script chosen at random from a third party repository and executes it, with no checksum, no review step and no way to see what will run before it runs. That is a reasonable thing to know about before copying the line.

Theme families are the real structure of the list

The collection is about a hundred and seventy entries, and the interesting part is not the count but how the entries group. Some themes come in day and night pairs under one family name, others come in three or more. The Solarized family alone has five entries, including a higher contrast variant and one marked as patched. The Tomorrow family has six, including a blue variant, a bright variant and an eighties variant. There is a Monokai Classic, a Monokai Pro, and then four Monokai Pro entries distinguished by a filter name each. Three entries under one family carry a leading digit rather than a word, which will sort oddly in any file listing. Four of the Monokai Pro filter entries have a preview reference in the file that is left dangling, with the image reference not closed properly.

Previews are kept in this repository and in another one

The previews for the collection exist in two places, and the README points at both. The first is the long list of entries in the README itself, where each theme name is followed by an image so the page becomes a visual index. The second is a separate repository, linked from the About section, holding a previews directory. That split is why the About section tells you that previews for each theme can be found either in the section below or in that other repository. The consequence for anyone automating this is that the images are not all in one place: the ones in the README are embedded in the document, and the ones in the companion repository are files in a tree that this project does not own.

Credits are generated from commit history, not written by hand

The contributor section is machine generated, and the configuration file for it sits at the root of the repository beside the licence and the contributing guide. The README links an emoji key, wraps the list in markers telling tools not to edit that section, and formats each person as a table cell with a name, a link and a single emoji whose tooltip explains the contribution. Those tooltips are the interesting part, because they name the kind of work rather than just decorating: one entry is credited for documentation, and several are credited for a new theme being added to the collection, each linked to a filtered commit history for that person. So the list can be regenerated from the commit log rather than maintained by hand, and the roles are coarse on purpose.

Editorial conclusion

This is a good collection if you want to try a lot of colour schemes quickly rather than settle on one, because the two preview commands let you switch without editing anything. Three things to know before you commit to a theme. Licensing is per scheme, not per repository, so read the citation inside the file you like. Switching themes means re-pointing a symlink named theme.conf, which is fine manually and awkward in a script. And there are no releases at all, so if you install through the conda package you are getting whatever that channel last built rather than a version you can name.

Frequently asked questions

Official sources

1. dexpota/kitty-themes on GitHub
2. Issues
3. License: MIT
4. README