7 ms·

Facebook deleted their Python SDK repository without warning

150 points by lincolnq 15y ago

Pewpewarrows 15y ago
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 https://github.com/benliles/djangopypi
- deleted 15y ago
  [deleted]
- wyuenho 15y ago
  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/ 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.
liuliu 15y ago
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.
thinkbohemian 15y ago
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?
- beagle3 15y ago
  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.
  - sirclueless 15y ago
    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.
- Pewpewarrows 15y ago
  Yes. We have the cheese shop: http://pypi.python.org/pypi http://pypi.python.org/pypi There's a few command-line programs to access it from, the most popular right now being "pip".
- jaylevitt 15y ago
  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.
steve8918 15y ago
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?
- lincolnq 15y ago
  No, they indicated it was "by design" in the bug report. I suspect they decided it wasn't worth their time to maintain it.
dinedal 15y ago
"Hey, we don't have time to update the Python SDK, what should we do?" "Just delete it."
bluemoon 15y ago
We just had to deal with this, there is a fork of the repository here https://github.com/pythonforfacebook/facebook-sdk 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.
dmpayton 15y ago
And yet, they're sponsoring PyCon 2012. https://us.pycon.org/2012/sponsors/#sponsor-89 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.
- ericflo 15y ago
  I don't understand this reasoning. You have nothing but contempt for Facebook because they sponsor PyCon 2012?
  - dmpayton 15y ago
    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.
    - rgc4 15y ago
      There's no reason why Facebook, with their size and engineering talent [citation needed]
      - uxp 15y ago
        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.
llambda 15y ago
Alternatively this fork seems active and is functioning for us: https://github.com/pythonforfacebook/facebook-sdk https://github.com/pythonforfacebook/facebook-sdk
dguaraglia 15y ago
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 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.
- lincolnq 15y ago
  Thanks. I updated my post to point to this one.
- casey 15y ago
  Sorry I couldn't help more, internally a lot of us were surprised by this move also.
- georgemcbay 15y ago
  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.
Toddward 15y ago
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 http://news.ycombinator.com/item?id=2737965
bryanh 15y ago
It looks like its back: https://github.com/facebook/python-sdk https://github.com/facebook/python-sdk
douglasp 15y ago
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/ https://developers.facebook.com/blog/post/568/), deprecating the REST API (https://developers.facebook.com/blog/post/616/ https://developers.facebook.com/blog/post/616/), moving to support OAuth 2.0/HTTPs (https://developers.facebook.com/docs/oauth2-https-migration/ 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).
- yock 15y ago
  Are you at liberty to share the reasons behind supporting these platform-specific SDKs rather than providing a single, robust REST API?
  - timdorr 15y ago
    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/ http://developers.facebook.com/docs/reference/api/
BiosElement 15y ago
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.
cookiecaper 15y ago
I have a fork here: https://github.com/sjuxax/python-sdk https://github.com/sjuxax/python-sdk This is the only significant change: https://github.com/sjuxax/python-sdk/commit/9aa42acaef53a7f5f1825db9d1b5818b46275a7e 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.
togasystems 15y ago
Is FQL going anywhere?
nfriedly 15y ago
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 https://github.com/nfriedly/connect-js

150 points by lincolnq 15y ago

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 https://github.com/benliles/djangopypi

deleted 15y ago
[deleted]
wyuenho 15y ago
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/ 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.

liuliu 15y ago

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.

thinkbohemian 15y ago

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?

beagle3 15y ago
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.
- sirclueless 15y ago
  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.
Pewpewarrows 15y ago
Yes. We have the cheese shop: http://pypi.python.org/pypi http://pypi.python.org/pypi There's a few command-line programs to access it from, the most popular right now being "pip".
jaylevitt 15y ago
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.

steve8918 15y ago

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?

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

dinedal 15y ago

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

bluemoon 15y ago

We just had to deal with this, there is a fork of the repository here https://github.com/pythonforfacebook/facebook-sdk 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.

dmpayton 15y ago

And yet, they're sponsoring PyCon 2012. https://us.pycon.org/2012/sponsors/#sponsor-89 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.

ericflo 15y ago
I don't understand this reasoning. You have nothing but contempt for Facebook because they sponsor PyCon 2012?
- dmpayton 15y ago
  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.
  - rgc4 15y ago
    There's no reason why Facebook, with their size and engineering talent [citation needed]
    - uxp 15y ago
      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.

llambda 15y ago

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

dguaraglia 15y ago

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 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.

lincolnq 15y ago
Thanks. I updated my post to point to this one.
casey 15y ago
Sorry I couldn't help more, internally a lot of us were surprised by this move also.
georgemcbay 15y ago
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.

Toddward 15y ago

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 http://news.ycombinator.com/item?id=2737965

bryanh 15y ago

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

douglasp 15y ago

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/ https://developers.facebook.com/blog/post/568/), deprecating the REST API (https://developers.facebook.com/blog/post/616/ https://developers.facebook.com/blog/post/616/), moving to support OAuth 2.0/HTTPs (https://developers.facebook.com/docs/oauth2-https-migration/ 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).

yock 15y ago
Are you at liberty to share the reasons behind supporting these platform-specific SDKs rather than providing a single, robust REST API?
- timdorr 15y ago
  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/ http://developers.facebook.com/docs/reference/api/

BiosElement 15y ago

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.

cookiecaper 15y ago

I have a fork here: https://github.com/sjuxax/python-sdk https://github.com/sjuxax/python-sdk This is the only significant change: https://github.com/sjuxax/python-sdk/commit/9aa42acaef53a7f5f1825db9d1b5818b46275a7e 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.

togasystems 15y ago

Is FQL going anywhere?

nfriedly 15y ago

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 https://github.com/nfriedly/connect-js