Please use flickr-with-uploads instead.
And don't you go thinking, "Oh, I'll just use the legacy package, it's surely better, with less fancy crap." No. It's more broken. That's all. The documentation is all over there, too... just not quite merged in properly, yet.
Don't worry, I care about documentation, it'll make sense again soon, but if your antsy-pants ass really wants, here's a blast from the past: the original flick-sync README.md.
So, yeah. Newer, better, faster, stronger, etc. It doesn't create duplicate photosets, and it has a
cleanup command if you have duplicate photosets you want to merge together.
This is a note-to-self, mostly, in case I think, sometime in the future, "Gosh, that was a stupid choice, what about modularity? This should totally be its own module!"
I will still think that, then, but here's why I merged them now:
Photo. These are pretty generic, and I realized they ought to go with the more general API code. This meant it would bring in a few dependencies, namely
asyncis a good library to have around, so, cool.
flickr api ...CLI calls belong in the main API package, too. Even though that functionality is, strictly speaking, above and beyond a basic Node.js API, I can only imagine that what's useful to me is useful to others.
flickr sync [Photo directory]. Yes, it's an extravagance to have it along with the rest of the API, but I didn't want to have to worry about merging CLI capabilities based on installed packages, or fracturing it into a
flickr-syncscript or something. So
flickr-syncis along for the ride, yes, but the rest really belongs in the API package. It shouldn't interfere with the fundamental functionality of that package—the basic request/response handling help—but it should be available in that package.
The overall price? Four additional dependencies:
But I like those packages (besides
winston), so no big deal. I think it's worth it.
Copyright © 2011–2013 Christopher Brown. MIT Licensed.