Thanks for the suggestions! I read your code and the support of images is awesome.

I would not assume everyone has sqlite but this can be done optionally with a plugin. Will consider writing a demo for this.

Using XDG directories and system secrets sounds a lot better than what I did. I will learn how to use them and try to integrate them with my code!

> I would not assume everyone has sqlite but this can be done optionally with a plugin. Will consider writing a demo for this.

Used to be everyone used BerkleyDB or some similar key-value store - for a great many usecases SQLite is just pragmatically better.

And it's arguably less exotic than perl.

You should of course do what want - but "just use SQLite" is pretty solid advice when dealing with structured data - and almost certainly better than "smart" text file.

I can't deny the benefits. But in my mind, this is not what ell should take care of. It doesn't intend to store anything whether in a text file or any other format. It should however provide the posibilities for users to store them in any way they like.

Fair enough. I seem to recall a project for keeping infinite bash history that did leverage SQLite - interfacing with such a project might be more interesting.

I was more thinking from gp comment that the project might store context or history in its own files - and then SQLite might be a good fit.

Atuin! https://atuin.sh/

This looks nice! Thanks for mentioning it. I should definitely install this on my servers.

You may be thinking of McFly —- it’s very good.

Shameless plug: we maintain a cross-platform/cross-language secrets store (with cli tooling available) to portably read and wrire secrets (but it doesn’t use the OS facilities for encryption).

Linking to the rust implementation because it’s the fastest and most easily portable: https://github.com/neosmart/securestore-rs

>I prefer using system secret stores to environment variables

What is the recommended way to store secrets in a Linux dev machine? The requirement is random scripts and programs should be able to load their secrets like API keys at runtime with minimum hassle. And the secrets shouldn't be stored on disk in plain-text.

I see you recommended keyring [1]. Is this "the GNU/linux way"? I see another possibility being storing them in an encrypted filesystem (whether FUSE-based or not)

[1]: https://github.com/llimllib/gpt-bash-cli/blob/841682affe2d0e...

I did a fair amount of looking to try and support a Linux secret store! My conclusion was that I was too confused and so I punted to keyring which seemed to paper over a few different stores.

It seems like a classic story of unfortunate Linux fragmentation

On the contrary please don't use the keyring, its annoying and some systems don't have it. Your llm key is not that critical, and you should trust what runs on your system.

Poetry demands access to my keyring and I don't use poetry (open bug for years, it doesnt even need access).

I know that it's contraversial. It would be an option or even a customized way of using ell mentioned in document. I wouldn't force users to adopt any unmatured or uncommon standard.

I don't have sqlite, and I wouldn't know how to use it.

I would much prefer text files.

Thank you.

you can visit the website https://www.sqlite.org/ where you can find copies of the program, along with instructions on how to use it. I would prefer to use a more advanced file format to hold records. Standing on the shoulders of giants, instead of their toes, as it were. Hopefully we can advance technology beyond the 1980's. Thank you for your understanding.