Facebook deleted their Python SDK repository without warning | Hacker News Reader

Facebook deleted their Python SDK repository without warning

techhouse.org

150 pointslincolnq45 comments

I work at Facebook.

My short response is that the repository is public once again, with a notice that it is deprecated. I personally apology for the churn.

My long response is that we haven't supported this SDK for some time and with our recent move to OAuth 2.0 across the board, the SDK does not support the latest cookie format. The reason we made the repository private was to avoid confusing developers with a public SDK that just didn't work and that we already said we didn't support.

You may be wondering why we don't support this SDK. The answer is very simple, resources. What we have been doing all year is reduce the surface area of our platform to a place that we can actual provide good support. This is the reason that we are removing FBML (https://developers.facebook.com/blog/post/568/), deprecating the REST API (https://developers.facebook.com/blog/post/616/), moving to support OAuth 2.0/HTTPs (https://developers.facebook.com/docs/oauth2-https-migration/) across the board and deciding what SDKs we are really going to support.

Based on this, we are going to do two things. First, we have made the repository public again, with messages that it is now deprecated. Feel free to clone and mod to taste/work. We really want to support a Python SDK, but we need to get all our resources focused on the SDKs we can actually support well. I have no doubt that the developer community can and will provide an SDK to fill this need in the interim. Second, we are going to post something on our developer blog to make sure everyone is clear about what SDKs we support (at this time we are only supporting the PHP SDK, the Javascript SDK, the iOS SDK and the Android SDK).

Are you at liberty to share the reasons behind supporting these platform-specific SDKs rather than providing a single, robust REST API?

They have that single, robust API in the form of the Graph API. It does everything the old APIs did and more, but it's all in one place now. http://developers.facebook.com/docs/reference/api/

I understand Facebook deprecated the REST API, but could you stop cloaking the documentation?

If I visit with my normal useragent I get a log-in form. If I visit with the Googlebot useragent I get content.

http://developers.facebook.com/docs/reference/rest/

Unrelated to this issue but I can't find any other way to contact you since you don't respond to email: when are developers' OpenGraph actions going to get approved? Mine have been pending for months. Why release the docs so early if no one's actions will get approved?

Maybe I'm confused. It seems like Facebook has the ability to hire as many 'resources' as they possibly can. Are you saying that there are no Python developers out there that you could hire that would be willing to work on the SDK?

I think he's saying the cost/benefit of providing the level of support for a Python SDK isn't worth it. Perhaps, once they've gotten everything cleaned up, they'll support Python again.

I like this idea. The FB API is a mess that I've decided to stay away from. If they consolidate their resources, improve the API and provide good docs, I'd be willing to revisit.

Just because a company has the resources to hire doesn't mean it necessarily should. A company culture can only absorb so many new hires in a given period of time, and I think Facebook likes the culture and doesn't want to see it go away.

One recurring point on HN in recent times is that there is a major talent shortage. It is very possible that Facebook is not able to find skilled Python developers to work on the SDK.

From everything that I've read and seen first hand in doing interviews, the reason for the major talent shortage is because FB, Goog, etc have first dibs on the best people. What I suspect is more likely is that their general interest primarily lies in languages other than Python.

Copy-paste from another comment:

FriendFeed, acquired by Facebook in 2009, was a Python shop. These guys now maintain their Tornado platform as Facebook (https://github.com/facebook/tornado). Facebook's CTO, Bret Taylor, is a Python guy (https://github.com/finiteloop). Python is used in house. They have the resources to support Python. They've just made the business decision not to.

"They have the resources to support Python."

Having Python experts on staff is no indication that those people have time to work on additional Python projects. And if there is a real talent shortage, it is quite likely they cannot find anyone else to take on the extra projects.

Ultimately, you are right that it is a business decision. They could hire anyone off the street and train them to be skilled in Python. Though I understand why they might not want to do that.

That's fair. I was more intending to point out that Facebook does indeed have Python developers, and they are not entirely a PHP business.

I might be a bit naïve thinking this, and I only ask out of curiosity, but, OAuth non-browser implementation issues aside, what drove the decision to support four individual SDKs to access the Graph API as opposed to building the Graph API up into a resource that, like a well implemented REST API, could be used easily by anything that can make an HTTP request?

From that position, the open source community, or any enterprising developer for that matter, has a single, standard, and well supported API they can then write a language specific library for and maintain.

Like I say, I'm not privy to all the details behind this, and I'm being wilfully ignorant, but it intrigues me that the developer of an API feels that it needs to then support its own abstraction of it for a limited number of platforms/languages.

I don't know the details, but to your and latchkey's point, I think the reason they support these SDKs (in addition to their generic Graph API) is that they're consumers of those SDKs. They have an iPhone app, an Android app, use JavaScript and probably the PHP SDK for internal stuff. So they're just making these public since they're good enough for internal use.

They could probably easily hire a Python coder to maintain a Python API (and Ruby, or whatever language), but it would be unrelated to the main work they're doing and probably lag behind since those languages are either little used or not used at all in house.

Python is used in house. They have the resources to support Python. They've just made the business decision not to.

Rule #42 of Deployment: Never rely on any external resources.

This isn't just to prevent getting caught with your paints down when a developer deletes a repo from a hard-coded URL. PyPI itself is known to go down more than [insert NSFW comment here]. You can either keep a local hard-copy of dependencies in your repo (ugly), or run an internal PyPI server using something like Chishop (which is now called djangopypi) [1].

Best-practices rant aside, thanks lincolnq for providing a backup fork of the project. And thanks Facebook for deleting a resource that developers have become reliant on without any notice whatsoever. Although that really shouldn't come as a surprise to anyone that's had the displeasure of using their excuse for an API.

[1] https://github.com/benliles/djangopypi

There are literally 240 forks of this essentially abandoned and/or poorly maintained Python SDK since May 2010 I think, and I think they just put it back with a notice to say it's deprecated. To be honest, I think people just fork the hell out of it, improve on it and find a common location for merges until Facebook releases a new one. If they don't, the community should just hack up a new one. The Facebook API changes every week and breaks every other week in 1 thing or another anyway. The community would probably respond faster and better to these changes than Facebook. It would be best if we could just agree on a central location for fork merges.

I personally just keep a modified version of this fork in my repository.

https://github.com/liorsion/python-sdk/

A note on DjangoPyPI and PyPI in general. I think it's about time we have a feature complete, stable, alternate PyPI implementation now. I tried virtually all the PyPI implementations out there a couple months ago and eventually had to settle with DjangoPyPI very reluctantly. It has trouble sitting behind a proxy and deleting things. In short, it's a mess, but it's the best in terms of features supported out there right now. It's a sad state of affairs, but Python should, and can do better than this. There's no way we can't have something like Maven or RubyGems.

I contacted one of the developers (Casey Muller) a few days ago when I noticed the repository had disappeared. I'm quoting from his reply:

"""This is pretty lame, apparently it was really out of date and we're having trouble finding the resources internally to support it.

For now we're pointing people here: https://github.com/pythonforfacebook/facebook-sdk """

Although I think the sudden disappearance wasn't a smooth move, I guess the community will have to step up and maintain the library. Nothing wrong with that, it was open source to begin with.

Thanks. I updated my post to point to this one.

Sorry I couldn't help more, internally a lot of us were surprised by this move also.

The problem with expecting the community to step up and maintain the library is that Facebook's URL level API is a complete disaster. Badly documented, frequently changing for no apparent reason, often breaks in subtle ways for weeks on end and then they ignore you when you bring it up, what documentation they do have is often blatantly wrong, etc.

I don't think you'll get much community support behind maintaining an API which relies on their URL-based APIs unless the people involved really, really need this functionality. The mess Facebook has created with their APIs makes this a very non-fun itch to scratch for its own sake.

And yet, they're sponsoring PyCon 2012.

https://us.pycon.org/2012/sponsors/#sponsor-89

I have nothing but contempt for Facebook at this point. As a user I don't trust them, and as a developer I can't stand them.

I don't understand this reasoning. You have nothing but contempt for Facebook because they sponsor PyCon 2012?

On the contrary, I think it's great that they're sponsoring PyCon! I'd love to see more companies get involved, including the one I work for. I was merely pointing out the hypocrisy (for lack of a better term) of them sponsoring PyCon and then nuking their Python SDK.

There's no reason why Facebook, with their size and engineering talent, shouldn't be able to allocate the resources to maintain their Python SDK. Making it the 20% project of a single engineer would be enough, I should think, with a few extra hours thrown in when major API changes come through. Even if they let the community drive the bulk of development, they really can't spare a few hours a week to look over bug reports and pull requests?

It's easy to write a check, but I'd like to see them take some real action and make Python a first-class citizen for Facebook app development.

There's no reason why Facebook, with their size and engineering talent [citation needed]

You may not like the company, and you are entitled to have that view (I might even share it!), but to state that everyone that works there in some form of engineering capacity is lacking of praise for their engineering feats is quite disingenuous.

Take a look at all the different repos they have on their github page, along with projects like HipHop-PHP, Cassandra, Tornado and the thousands of commits they have contributed to MySQL, PHP, memcached, Varnish. Let alone the number of sites they integrate with and their active user base, Facebook's engineers are quite intelligent and have solved some amazing problems. I'd like to think that most of HN thinks like engineers and marketers, positions that generally do best when their time isn't wasted by flinging mud for political "gain". Please keep it that way.

"Hey, we don't have time to update the Python SDK, what should we do?"

"Just delete it."

I seem to recall Facebook announcing at the beginning of the summer that they were discontinuing support for the Python SDK. I'll try to track down the relevant article.

EDIT - Relevant HN link: http://news.ycombinator.com/item?id=2737965

Alternatively this fork seems active and is functioning for us: https://github.com/pythonforfacebook/facebook-sdk

That's why I always fork important libraries that my application relies on especially Facebook SDKs as most of them need some tuning to work in the first place (!). Yes, it takes some efforts to keep the library up to date, but it also avoid any broken changes introduced to your deployment without warnings.

Linking directly to the Git repo can lead to bad things, this being one of them. Ruby has rubygems, a managed version-ed dependency system that is one layer removed from source control. Does python have a system like Rubygems?

PyPI is the index; The "ruby gem" equivalent is the "python egg" (not exactly equivalent, but close enough for this discussion) And pip and easy_install are the management system.

It's surprising how little known these things are - compared to e.g. Ruby Gems, CPAN, CTAN, CRAN and npm.

Given how much of a pain in the ass it is to manage python packages, I'm not really that surprised. CPAN is distributed with perl, rubygems is packaged with ruby in most package managers, npm is actually a native part of the node project now. But pip (the only proper system for managing python packages in my opinion) isn't even a blessed third-party package, it's just another package on PyPI unless you know better already. I think python just has the trouble that they started off on the wrong foot before anyone knew what worked best, and they've been playing catch-up with various coats of paint on top of their proverbial pig.

Yes. We have the cheese shop: http://pypi.python.org/pypi

There's a few command-line programs to access it from, the most popular right now being "pip".

RubyGems doesn't have anything particularly better here, unless you're maintaining your own gem server. If Facebook deleted the repo and the gemcutter published gem, you'd be in the same boat. If gemcutter disappeared (even temporarily due to an outage), you'd also be stuck.

In general, you should mirror external dependencies to the extent you're risk-averse. Mildly paranoid startup? Fork any github repos that might disappear and that don't already have forks you trust. Running a large financial institution? Run your own gem server, apt repo, etc.

Having something more like CPAN would be preferable because its mirrored on over 400 sites across the world (http://mirrors.cpan.org/) and should any CPAN author decide to delete any of their modules/distros then it is still accessible via BackPAN (http://backpan.perl.org/).

I suppose this is one of the great advantages of CPAN being developed in the era of modem based internet :)

I have a fork here: https://github.com/sjuxax/python-sdk

This is the only significant change: https://github.com/sjuxax/python-sdk/commit/9aa42acaef53a7f5... , to fix crashes when handling profile picture downloads. It's hackish but it was all I needed for my project so I rolled with it.

This version of the library installs as sjuxax-facebook. I'm not sure if it still works, I haven't tried to use it since October.

Facebook's github page for their JS SDK is similarly borked. It's so horribly outdated that someone was saving copies of the minified js files to de-minify and then diff them to see what had changed. I thought that was a great idea and set up some scripts to do it automatically: https://github.com/nfriedly/connect-js

We just had to deal with this, there is a fork of the repository here https://github.com/pythonforfacebook/facebook-sdk I think part of the reason they removed the repository was because there were some changes to the way they handled the cookies, this fork however fixes that and does work.

I don't see why this is the end of the world really. Sounds like it was just a basic depreciation, but frankly I don't see why anyone would expect it remain online forever.

I'm trying to understand why Facebook would delete the SDK without any type of notice or deprecation. Was it possibly a mistake of some sort?

No, they indicated it was "by design" in the bug report. I suspect they decided it wasn't worth their time to maintain it.

It looks like its back: https://github.com/facebook/python-sdk

Is FQL going anywhere?

Reply on news.ycombinator.com