Introducing Leo

Leo is a CLI tool that lets you scaffold and quickly create scripts and run them through a unified interface. It’s highly configurable and ships with a JSON data store accessible from the unified CLI.

Terminal window displaying command-line instructions for the Leo tool, including command list, flags, and usage examples.

Why?

Over the years I’ve written a lot of scripts for myself for various reasons – automating repetitive tasks, cron jobs, text manipulators, meme makers etc. I usually throw them all into my home directory and invoke them through shell (zsh) functions or some directly. This can get out of hand and maintaining them has always involved manual efforts from my side. Some, I even stopped using because of the maintenance efforts.

With LLMs, it became easier, but it still needed effort from my side.

I needed a unified interface to run all of my custom scripts.

At first, I tried using task runners and they usually tend to come with their own baggage. They felt like they worked well if the scripts belonged to a single project.

None of them supported data storage. I had to manually write my own and maintain it. Over years, I saw myself using it more and more to store a lot of things in there and I had to customize it so much to fit my requirements.

After gathering all these requirements, I figured I’d write something that unifies running random scripts without forcing a major change and having a data store to access any required variables. It started off as a Makefile and evolved into a CLI tool of its own.

Features

Plugins

Leo has a scaffolding feature to generate plugins using common languages. You can use your existing scripts with Leo, as long as you name them leo- and make them available either in the PATH or your configured path to store Leo’s scripts, commands.

Also, you can have your own workspaces based on your computer. For instance, I have a default workspace which I use for my scripts that I use on both – my personal and work MacBooks – and a work workspace which I use for my work related scripts. They’re both configured to be at different locations. The default one is synced in my dotfiles repo and the work one on my work computer.

Data store

It’s a simple JSON store that has some fun UX features to it.

For instance, if you store the path to a file, it’ll not just copy the path, but it actually copies the file to your clipboard, ready to paste into Slack, Telegram, Teams, or even Finder. For me, this was such a big deal and I love it so much.

leo store set foo /Users/golu/foo.png

This will be stored as a string. But when you copy using clip, it’ll be copied to your clipboard as a file.

leo clip foo => PNG image ready to paste

You can always get just the string path too.

leo store get foo

This is more for retrieval. Nothing special.

Configurable

Leo let’s you configure your data storage path, default language for generating new scripts, command paths (where you store your scripts), and workspace.

I’ve included an interactive way to configure Leo via leo config setup.

Get Leo

Leo is distributed via Homebrew.

To install Leo,

brew tap stealthfactory/leobrew trust stealthfactory/leobrew install --cask leo

To update later,

brew update && brew upgrade --cask leo

In order to distribute Leo via Homebrew as a binary file with 0 dependencies, I had to jump through hoops. I had to renew my Apple Developer account membership to obtain the necessary certs to notarize and sign the binary file. And because this is a bin file, I couldn’t use a Formula, I had to use a Cask, which is the recommended way to handle bin files in Homebrew.

Open Source

I’ve decided to open source Leo under MIT license. You can find it here: https://github.com/StealthFactory/leo

If you think you have a use case that Leo solves, give it a shot. As always, contributions are welcome.

At the time of publishing this blog post, leo is v0.6.1 years old.

This is a Stealth Factory make and is the first published open source software. More on that later

添加评论
点赞收藏
点踩分享查看原文
评论
?
参与讨论