Another comment already mentioned Khard, which has been around a while. [0]
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.
> 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.
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.
I'm aware of that approach for Python, and Bundler can be configured to do a similar thing for Ruby. Those are good approaches for development environments (though I generally prefer Docker for those these days), but for system tools I think that's just kind of a hassle and I don't want to do it.
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.
This is maybe slightly different than what you’re looking for, but my project Friends[1] is a journaling CLI that I also use to keep track of people’s addresses and contact info (via the “notes” feature).
This is an interesting idea. The way the commands look like filesystems makes me wonder how hard it would be to make a FUSE filesystem for contacts based on this premise.
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.
People could share identities as files, have public keys and contact infos, or maybe even content? Would that count as distributed social network? It would work really well with mobile
I want to say that BeOS did this back in the day. I don’t think it was specifically a FUSE mount, but rather that the contacts application read vcards (or something similar) stored as plain files in the file system. Then the Contacts app just needed to be pointed to the proper folder and it would work.
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.
Grep is so handy. I want to say I also used something like 'ar -i' on one of my systems for a while, but then it went away and I never looked it up again.
I really like the simplicity of the idea but feel like the elephant in the room is: What about having your contacts on mobile?
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.
That's great for a notepad but don't do anything for knowing who contacts in text messages and call logs, incoming calls, etc are. It feels like half of a solution to me.
I'm a command-line person, and I've tried a couple of different options for online contact managements since 1993.
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.)
A few months ago I was looking around for a good personal CRM and I thought airtable would possibly be the way to go. One thing I'd like is to be able to attach multiple pictures to any given contact entry.
Very cool! I wish macOS contacts were supported. I would not migrate to something that doesn't solve the "sync b/w devices" problem. It would be pretty nifty to have a CLI frontend for iCloud contacts.
I liked this command-line tool better back when it was called Finger, and the contactee controlled which information was current and correct in their .plan and .profile files.
I just store mines in a small sqlite DB and use emacs's sql mode to query them along with a bbdb syncronization for my email, org-contacts and a small web frontend over a kubernetes cluster to get them online from my mobile,
42 comments
[ 76.7 ms ] story [ 686 ms ] threadThere'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
[1] https://github.com/pimutils/mates.rs
[2] https://github.com/pimutils/vdirsyncer
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.
[1] - https://pypi.org/project/pipx/
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.
[1]: https://abook.sourceforge.io/
[1] https://github.com/JacobEvelyn/friends
* 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.
[0] https://github.com/scheibler/khard
- https://github.com/pimutils/vdirsyncer
- https://isync.sourceforge.io/mbsync.html
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.
https://datatracker.ietf.org/doc/html/rfc6350
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.
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
https://github.com/ggreer/the_silver_searcher
https://geoff.greer.fm/ag/
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.
So contacts are my address book.
And the contents are just toml files, eg Edit: I also wrote a little script that will crawl the contacts and build out a vCard for phones, email, etc. This works for me.[0]: https://www.passwordstore.org/
[1]: https://github.com/rabbit-ci/toml2json
... And it looks like such a thing somewhat exists! https://github.com/keith/contacts-cli
And DAVx5 https://www.davx5.com/
works well,