Google's contacts.vcf to ppl

[shushcat]

I ran across two problems while trying to import my contacts.vcf file from Google Contacts into ppl.

1. Since there isn't any way to split the contacts file into separate cards using ppl, I ended up needing to write a few Python scripts to split the files, format the short names correctly and rename the files based on the short names. I would have used Ruby, but am not particularly familiar yet. If anybody is interested extending ppl to include this sort of functionality and thinks my code might be helpful to them, I'd be happy to share it.
2. And related to the first, ppl's ls function totally falls apart if there are ^M characters ending fields. Trying to run ppl ls if even one of your contact cards has these characters in it leads to scrambled output from the offending card, with no other indication of what the problem might be and no list to speak of.

This project is definitely something I've been needing, so I'd be more than happy to try and put a Ruby solution together for these problems. But, like I said, I'm pretty amateur at GitHub and Ruby still, so am definitely not the best choice if this is something people would like implemented quickly.

[henrycatalinismith]

1. I would be super interested to see that code, yeah. Google Contacts integration isn't something I've put much thought into as it's not something I've tried to do myself. It'd be helpful to have a look at the scripts you wrote to get an idea of how feasible it'd be to build something robust enough to be shippable for general use. I know of a similar-sounding thing called gv-contacts but I think that might be specific to Google Voice.
2. Yep, hadn't thought of this. Those ^M characters are like beach sand. You spend a few minutes near a Windows machine and then it takes days before they're completely cleaned out of everything. The only thing I'm not sure of is whether to deal with this by sanitising incoming data, output, or both. Either way, I'll get around to this at some point soon. I'm trying to be disciplined about fixing bugs before adding new bugscreating new features, and this is definitely a bug, so it shouldn't be long,

[shushcat]

Alright, I cleaned the script up a bit and made a repository for it here. I hadn't seen the gv-contacts project before, but its page says that the contacts list used by Google Voice/Mail are the same, so it achieves the same effect. That said, I do think there are people out there who would like to get their contacts out of Google and keep them out without the extra stuff that goes with gv-contacts. Hopefully goog2ppl can help with that. Also, depending on whether or not you think this sort of functionality is something which should be included in ppl, I will either take down or leave up the goog2ppl repository to minimize confusion.

[henrycatalinismith]

Very nice, I just tried this out with my own exported contacts.vcf from Google. I'd been interested in seeing how that dataset would behave once imported into ppl, so thanks!

I see what you mean about the carriage return characters, by the way. Google generates it that way, apparently. So I'm glad you brought that up as it's pretty important for compatibility with contact data exported from Google.

I think we should leave it as its own repository for now. My plan for this evening is to invest some quality time in the documentation, and as part of that I think I need to add an entire section about integrating ppl with other software. Google Contacts is one such piece of software, so would you mind if I linked to your repo from there?

Also, you've gone to all the trouble of writing this and uploading it so I feel I owe you an explanation about why I'm not clamouring to build a Ruby version and incorporate it. I know Google sync is important to a lot of people, but it's too much of a scope change for me personally compared to the direction I want to spend my time taking ppl in. By remaining strictly a middleman between git, vCard and the command-line, ppl should hopefully only become more and more stable and complete as time passes, because none of those three things ever change or do anything weird. I'm nervous about straying far outside that comfort zone in case it opens a Pandora's Box of unreproducible bug reports resulting from strange API response data quirks, and endless code churn and toil under the yoke of Google's neverending API deprecation cycle.

That being said, I think stuff like goog2ppl is a really worthwhile use of time, and I'd even be interested in working with you a bit to iron out some issues I had with it if you wouldn't mind me submitting some issues?

[henrycatalinismith]

That being said, anything that can be done within ppl's scope to make life easier for such tools is worth discussing. For example, if such a thing would be helpful, I wouldn't be averse to extending ppl add to check stdin for vCard data. Something like that would be a good way of reducing "version friction", since obviously some day it could become necessary to change the implementation details of ppl's git storage system for some as-yet-unknown reason.

[shushcat]

Totally understand the desire to limit ppl's scope, and I've no problem whatsoever either with your linking to or reporting issues for goog2ppl.

Thanks for responding so rapidly and thoroughly!