Ppl: The command line address book
github.com
github.com
So contacts are my address book.
pass edit contact/john.smith
name = "John Smith"
email = "john@example.com"
pass show contact/john.smith | toml2json | jq '.email'
A downside is that it doesn't integrate with all those fancy services, but the upside is it doesn't integrate with those fancy services either.
This ppl project has those advantages too
It looks like ppl has the ability to import from Google Contacts etc but without a two-way sync mechanism to keep the contacts on my phone up-to-date it's hard to see adopting this.
Maybe if there was the ability to do simple diff and apply like gmailctl that would be good enough.
Existing software stacks (commercial and open source) have shown poor support for file formats, and there is usually some level of loss when exporting/importing as a consequence.
Ultimately, UTF8 plain text is hard to beat as the most durable format.
I've also written scripts to extract contact details from MBOX-format e-mail repositories automatically, to support my manually-curated contacts file. Anything not found in the primary file may be in the (messier) secondary file.
I like the ppl idea, but the realization lacks generality: many people I interact with have multiple roles, so it's not uncommon to have 2 phones and 3 email addresses, and several postal addresses (I think I just saw ppl's Ruby class can just manage two emails, hardwired). Also, I think ergonomically it's not a good choice to edit one field at a time over the command line. Even I as a die-hard command liner want to be able to edit a person's full entry at once in Sublime or Emacs. I also need to see a person's record completely togehter on the screen, not just one line at a time. Finally, a free-text field (to remind oneself where I met anyone, and to store hash tags for topics) and a great search (supporting approx. string matching) is a must-have feature that I rely on heavily.
I concur with others that a static binary is preferred for such a function to avoid dependency issues.
(Thanks to the Ppl authors for getting the conversation started about effective contacts management, I'm keen to learn more about how everyone else is doing it.)
The little-brother database allowed looking up contacts from LDAP, and similar, and pulling from local files.
One "mount -t contactsfs contacts ~/contacts" and you could literally treat your contacts as files!
What I don't like about programs like this is that they often don't respect the XDG folder configuration, resorting to ~/.pplconfig and ./.ppl/config for default configuration paths. I've already went through all the stupid dotfiles in my home directory once, moving as many as I could, and I'm not going through all that effort again.
I definitely remember the email application working that way, but think contacts worked that way too.
It was quite a clever way of interacting with your system. Everything was still a file, but your client applications were a bit more clever in how they interacted with those individual files. It was very close to the file system as a DB concept that was popular at the time, but far more practical.
... And it looks like such a thing somewhat exists! https://github.com/keith/contacts-cli
And DAVx5 https://www.davx5.com/
There's also Mates [1]. Less mature, very simple, but it's what I personally use.
I try to steer away from relying on CLI tools implemented in python or ruby: at the system level they always seem to cause dependency hell problems eventually. Mates is implemented in Rust, so it's compiled, which is primarily why I chose it.
An important related project is vdirsyncer [2]. Ppl, khard, and mates all store data in vcard format but don't talk to APIs or sync anything. Vdirsyncer can sync your vcard collection with your email provider or what have you.
[0] https://github.com/scheibler/khard
For python specifically, you can use `pipx` which will install an app into it's own venv and activate that venv only as needed, with fully isolated deps. [1]
No such solution exists for ruby or php though, and I won't use those projects unless dockerized.
For a tool I install & use, my happy path is "install it with my package manager, and then stop thinking about it". Upgrades will happen whenever I decide to ask my package manager to upgrade everything. (I use Arch Linux, so that's usually once or twice a week.)
Needing to hand-setup an installation or deal with multiple package managers like that for a program makes me cranky. I've certainly done it when there wasn't a good alternative (and also occasionally wrap programs in docker containers as well if it's easier - https://github.com/wfleming/dockerfiles), but it's the kind of thing that makes me pause and reconsider whether I really care enough to use whatever the program is.
* not only contacts but also tasks, projects, notes and calendars
* not local, instead it uses a self hosted rest-like api wrapping a database centralizing all state
* embedded MQTT broker that publishes CRUD events so you can hook into any events to script automations
* cli client that works similar to this so commands can be chained in shell pipelines
* there's also a tui client (mutt-inspired) and I might do web/mobile later
It's far from finished, but if you're interested send me an email (link in profile) and I'll keep you up to date.
works well,