12 ms·

Ruby-FFI is no longer maintained

70 points by Dylanlacey 13y ago

msie 13y ago
Update: maintenance has been taken over by the JRuby team! Yay!
kawsper 13y ago
It could be nice if Rubygems could show which gems that depends on a specific gem. I have a feeling that quite a lot depends on FFI. I know that we depend on FFI, because we use selenium-webdriver, which depends on childprocess, which depends on FFI.
- mwill 13y ago
  Is this a big problem for someone in your situation? Can you not rely on childprocess (or selenium webdriver) to handle their own dependancies appropriately?
  - lstamour 13y ago
    Well sure, from the same perspective, the way this usually works is someone will take over the project -- whoever "needs it the most when they discover an issue" -- and so it's not necessarily anyone's problem. That is, after all, the somewhat selfish nature of Open Source. But I'd say this is a problem if one wants to ensure compatibility in Rubyland with other languages and processes on different environments, or that they're using the latest and most correct code for their situation. This gets hairier if the gem forks on github, and you've multiple fixes in multiple branches ... Rubygems aren't really set up to deal with this. Bundler helps, though.
  - kawsper 13y ago
    No, not really a problem for me, I would expect childprocess to change their dependencies if needed. I guess the reason that I am a bit uncomfortable, is because FFI in particular feels very basic and fundamental.
- deleted 13y ago
  [deleted]
- sqs 13y ago
  I'm helping build Sourcegraph, which lists the gems that depend on FFI here: https://sourcegraph.com/github.com/ffi/ffi/network/repos/in https://sourcegraph.com/github.com/ffi/ffi/network/repos/in and can show where some of its main methods are used: https://sourcegraph.com/github.com/ffi/ffi/symbols/ruby/gem/FFI/Pointer/$methods/read_string https://sourcegraph.com/github.com/ffi/ffi/symbols/ruby/gem/... and also for some other gems: https://sourcegraph.com/github.com/nex3/sass/network/repos/in https://sourcegraph.com/github.com/nex3/sass/network/repos/i... https://sourcegraph.com/github.com/lsegal/yard/network/repos/in https://sourcegraph.com/github.com/lsegal/yard/network/repos... https://sourcegraph.com/github.com/rails/rails/network/repos/in https://sourcegraph.com/github.com/rails/rails/network/repos... It would be great if someone added this functionality to rubygems.org (npmjs.org has it: https://npmjs.org/browse/depended/request https://npmjs.org/browse/depended/request). The Ruby support is very alpha right now. It works for some (but not all) popular gems, and it doesn't show transitive dependencies yet. Also, the list of dependents isn't comprehensive, but it should be a good starting point. If there are any specific gems you'd like to see dependents for, or any issues you see, let me know.
  - lstamour 13y ago
    At a glance, there are perhaps 1400 gems that require or refer to ffi: https://www.google.ca/search?q=ffi+inurl:gemspec https://www.google.ca/search?q=ffi+inurl:gemspec But that's the type of site I was trying to find before I resorted to Google. I'd second that recommendation to add the functionality to rubygems.org ... Maybe we need a pull-request? :)
    - sqs 13y ago
      I will probably eventually submit a PR for this feature at https://github.com/rubygems/rubygems.org https://github.com/rubygems/rubygems.org. If anyone else wants to get it started, I'd certainly help.
  - robotmay 13y ago
    Had a play around on SG and it works really well; nice project. What JS framework, if any, are you using?
- samstokes 13y ago
  You can tell it for a given project by looking in Gemfile.lock. It shows all the gems you explicitly requested in your Gemfile, and what dependencies each one pulled in. edit: assuming you're using Bundler, that is. If you're not, fix that first ;)
- edbond99 13y ago
  There is a list of several gems depending on ffi ( https://www.ruby-toolbox.com/projects/ffi https://www.ruby-toolbox.com/projects/ffi ), mostly system stuff: Popular gems depending on ffi childprocess, rb-inotify, rb-kqueue, rb-fchange, ethon, spoon, minitest-chef-handler, win32-process, libnotify, nfqueue, net-ping, rubypython, sys-cpu, sys-uname, gssapi
w0rd-driven 13y ago
This also seems to be an example of how not to no longer provide support. Close all the issues? Let no one take over? I guess a fork works but I've also seen projects clearly taken over as-is with seemingly "official blessing." I prefer the latter approach or at the very least, keep the thing untouched until someone steps up. I could be late to the party and someone finally got around to saying "tough shit, we're done here" after years of nothing. This just feels cold to me. I don't need a sugar coated reason if you're honest. You can easily say "all I get are windows support issues. Fuck windows!!!" and it'd be a thousand times better than what's there.
- deleted 13y ago
  [deleted]
- byroot 13y ago
  Yeah it's not great, but I wonder if I don't prefer this over maintainers that let their project die, don't answer PR/issues and never tell they would like someone else to take over. I mean, I understand that it's part of FLOSS, a maintainer owe nothing to his users, but adding a line to a readme to explicitly say it would be appreciated.
  - rmoriz 13y ago
    He probably burned out and the only feedback he got was about some irrelevant licensing foo. I've run into this myself and this pretty much destroys any motivation to hand over something, in which you have invested A LOT of time, to someone else in a clear way without anger. From a social aspect, github does not cover this. E.g. besides the technical stuff there should be an easy way to donate or contribute money to an author to honor his/her work. Some communities, like Ruby or Perl, do have yearly events to honor people that provide a lot of value to the community. A regular voting e.g. for the "Ruby Developer of the month" + 100$ sponsoring could probably help to keep motivation up and hard feelings down.
allr 13y ago
More importantly, FFI 1.9.1 was released today (http://rubygems.org/gems/ffi http://rubygems.org/gems/ffi) and completely broke knife-solo, returning a huge stack trace ending with: You may have encountered a bug in the Ruby interpreter or extension libraries. reverting back to FFI 1.9.0 did the trick.
- xentronium 13y ago
  1.9.1 is yanked as of now, which means no one can install it accidentally.
jvoorhis 13y ago
This is disappointing. I've created a number of FFI-based projects, and maybe have taken it for granted. I checked the mailing list archives, and did not see any warning signs or calls for new maintainers.
- petercooper 13y ago
  This might explain some of it (not the original tweet but go much further down in the discussion with regards to how the licensing was changed): https://twitter.com/bascule/status/393509979711213568 https://twitter.com/bascule/status/393509979711213568
protomyth 13y ago
Does anyone have a clue of why? I looked, and the only weird thing I can see is the restoring of BSD license text to some files.
- petercooper 13y ago
  I wonder if this is related to there being an extensive "discussion" on Twitter a few days ago about ffi's LGPLv3 license. One thread to start from: https://twitter.com/bascule/status/393509979711213568 https://twitter.com/bascule/status/393509979711213568 .. one of the concerns much later in the discussion seems to be how ffi changed from BSD to LGPL at some stage.
nnq 13y ago
I never understood why aren't more Ruby extensions build on FFI instead of the MRI C extensions way - it would make everything work seamlessly on JRuby or Rubinius or Maglev and would also involve much less work. ...hope someone of the big Ruby backers take this project under their wing.
Argorak 13y ago
So after reading this commit: https://github.com/ffi/ffi/commit/346c80ad6b8c0e6dc3c390b582a81b306e1ef5f9 https://github.com/ffi/ffi/commit/346c80ad6b8c0e6dc3c390b582... and this discussion https://twitter.com/bascule/status/393509979711213568 https://twitter.com/bascule/status/393509979711213568 I have the impression that no one can safely fork ruby-ffi without opening himself to legal trouble. It seems like the licensing of the project is a horrible mess. IANAL, so I hope I am reading this wrong?
- logn 13y ago
  It's not that big of a deal. It's an LGPL-licensed codebase which incorporated BSD-licensed modules (there's nothing wrong with that). Since LGPL places some requirements on being intermingled with incompatibly-licensed software, the author made sure to point out which parts were under the more permissive BSD license so people could re-use those parts and not be subject to LGPL by using his project as a whole. In a nutshell, if you use an LGPL codebase, make sure either: (1) your code is LGPL or under a compatible license or (2) that you only use the code on an API level and dynamically link to it. Btw, LGPL is a license accepted by many enormous communities, such as Qt. If you want to fork this project, easiest route is to just re-apply the LGPL license and fork after the point where notice of BSD parts was added, because it's a violation of BSD to not mention their license. IANAL
  - Argorak 13y ago
    I have no problem with the LGPL (beyond the occasional problem with legal, but thats legals problem) or the dual-licensing in general. The linked commit hints at additional problems with missing licensing etc. In the absence of good documentation on this, a new maintainer has the problem of not being able to make heads or tails of it if someone had claims on the code.
- rtb 13y ago
  I don't think that's the case. It appears to be LGPL + BSD. That should be fine for pretty much any use. "Postmodern" has it from the linked twitter thread: "they [are] probably confusing LGPL with GPL/AGPL, or are afraid of getting Stallman cooties."
izietto 13y ago
It's unfair that a so widespread project gets killed with so big lack of informations; FFI implementation is essential in every mature development platform IMHO.
ksec 13y ago
OH Great, another Project closed due to stupid and insane License argument and restriction.
yink 13y ago
Does anyone know the reason for closing this project? Wayne Meissner appears to have just protected his tweets https://twitter.com/wmeissner https://twitter.com/wmeissner
marti 13y ago
Ruby >= 1.9 also has a built in libffi wrapper, "Fiddle"[1], which can replicate basic Ruby-FFI functionality with some glue code[2]. There aren't many examples, but I've successfully used it to call Windows API (GDI+) functions. [1] http://ruby-doc.org/stdlib-2.0.0/libdoc/fiddle/rdoc/Fiddle.html http://ruby-doc.org/stdlib-2.0.0/libdoc/fiddle/rdoc/Fiddle.h... [2] http://www.slideshare.net/tenderlove/hidden-gems-of-ruby-19/134 http://www.slideshare.net/tenderlove/hidden-gems-of-ruby-19/...
- rmoriz 13y ago
  It would be awesome if someone can extend this and provide some kind of migration path for ruby-ffi users…
SmileyKeith 13y ago
That's definitely unfortunate. Seems like a lot of stuff I've done inadvertently requires ffi. And lately with Ruby 2.0.0-p247 on OS X Mavericks ffi 1.9.1 has been crashing..
username223 13y ago
As was said in the README: "The following people have submitted code, bug reports, or otherwide contributed to the success of this project:" But they can please to go die in a fire.
protomyth 13y ago
Here is a link to the "Cleaning up licensing" issue https://github.com/ffi/ffi/issues/288 https://github.com/ffi/ffi/issues/288

70 points by Dylanlacey 13y ago

msie 13y ago

Update: maintenance has been taken over by the JRuby team! Yay!

It could be nice if Rubygems could show which gems that depends on a specific gem. I have a feeling that quite a lot depends on FFI. I know that we depend on FFI, because we use selenium-webdriver, which depends on childprocess, which depends on FFI.

mwill 13y ago
Is this a big problem for someone in your situation? Can you not rely on childprocess (or selenium webdriver) to handle their own dependancies appropriately?
- lstamour 13y ago
  Well sure, from the same perspective, the way this usually works is someone will take over the project -- whoever "needs it the most when they discover an issue" -- and so it's not necessarily anyone's problem. That is, after all, the somewhat selfish nature of Open Source. But I'd say this is a problem if one wants to ensure compatibility in Rubyland with other languages and processes on different environments, or that they're using the latest and most correct code for their situation. This gets hairier if the gem forks on github, and you've multiple fixes in multiple branches ... Rubygems aren't really set up to deal with this. Bundler helps, though.
- kawsper 13y ago
  No, not really a problem for me, I would expect childprocess to change their dependencies if needed. I guess the reason that I am a bit uncomfortable, is because FFI in particular feels very basic and fundamental.
deleted 13y ago
[deleted]
sqs 13y ago
I'm helping build Sourcegraph, which lists the gems that depend on FFI here: https://sourcegraph.com/github.com/ffi/ffi/network/repos/in https://sourcegraph.com/github.com/ffi/ffi/network/repos/in and can show where some of its main methods are used: https://sourcegraph.com/github.com/ffi/ffi/symbols/ruby/gem/FFI/Pointer/$methods/read_string https://sourcegraph.com/github.com/ffi/ffi/symbols/ruby/gem/... and also for some other gems: https://sourcegraph.com/github.com/nex3/sass/network/repos/in https://sourcegraph.com/github.com/nex3/sass/network/repos/i... https://sourcegraph.com/github.com/lsegal/yard/network/repos/in https://sourcegraph.com/github.com/lsegal/yard/network/repos... https://sourcegraph.com/github.com/rails/rails/network/repos/in https://sourcegraph.com/github.com/rails/rails/network/repos... It would be great if someone added this functionality to rubygems.org (npmjs.org has it: https://npmjs.org/browse/depended/request https://npmjs.org/browse/depended/request). The Ruby support is very alpha right now. It works for some (but not all) popular gems, and it doesn't show transitive dependencies yet. Also, the list of dependents isn't comprehensive, but it should be a good starting point. If there are any specific gems you'd like to see dependents for, or any issues you see, let me know.
- lstamour 13y ago
  At a glance, there are perhaps 1400 gems that require or refer to ffi: https://www.google.ca/search?q=ffi+inurl:gemspec https://www.google.ca/search?q=ffi+inurl:gemspec But that's the type of site I was trying to find before I resorted to Google. I'd second that recommendation to add the functionality to rubygems.org ... Maybe we need a pull-request? :)
  - sqs 13y ago
    I will probably eventually submit a PR for this feature at https://github.com/rubygems/rubygems.org https://github.com/rubygems/rubygems.org. If anyone else wants to get it started, I'd certainly help.
- robotmay 13y ago
  Had a play around on SG and it works really well; nice project. What JS framework, if any, are you using?
samstokes 13y ago
You can tell it for a given project by looking in Gemfile.lock. It shows all the gems you explicitly requested in your Gemfile, and what dependencies each one pulled in. edit: assuming you're using Bundler, that is. If you're not, fix that first ;)
edbond99 13y ago
There is a list of several gems depending on ffi ( https://www.ruby-toolbox.com/projects/ffi https://www.ruby-toolbox.com/projects/ffi ), mostly system stuff: Popular gems depending on ffi childprocess, rb-inotify, rb-kqueue, rb-fchange, ethon, spoon, minitest-chef-handler, win32-process, libnotify, nfqueue, net-ping, rubypython, sys-cpu, sys-uname, gssapi

w0rd-driven 13y ago

This also seems to be an example of how not to no longer provide support. Close all the issues? Let no one take over? I guess a fork works but I've also seen projects clearly taken over as-is with seemingly "official blessing." I prefer the latter approach or at the very least, keep the thing untouched until someone steps up. I could be late to the party and someone finally got around to saying "tough shit, we're done here" after years of nothing. This just feels cold to me. I don't need a sugar coated reason if you're honest. You can easily say "all I get are windows support issues. Fuck windows!!!" and it'd be a thousand times better than what's there.

deleted 13y ago
[deleted]
byroot 13y ago
Yeah it's not great, but I wonder if I don't prefer this over maintainers that let their project die, don't answer PR/issues and never tell they would like someone else to take over. I mean, I understand that it's part of FLOSS, a maintainer owe nothing to his users, but adding a line to a readme to explicitly say it would be appreciated.
- rmoriz 13y ago
  He probably burned out and the only feedback he got was about some irrelevant licensing foo. I've run into this myself and this pretty much destroys any motivation to hand over something, in which you have invested A LOT of time, to someone else in a clear way without anger. From a social aspect, github does not cover this. E.g. besides the technical stuff there should be an easy way to donate or contribute money to an author to honor his/her work. Some communities, like Ruby or Perl, do have yearly events to honor people that provide a lot of value to the community. A regular voting e.g. for the "Ruby Developer of the month" + 100$ sponsoring could probably help to keep motivation up and hard feelings down.

allr 13y ago

More importantly, FFI 1.9.1 was released today (http://rubygems.org/gems/ffi http://rubygems.org/gems/ffi) and completely broke knife-solo, returning a huge stack trace ending with: You may have encountered a bug in the Ruby interpreter or extension libraries. reverting back to FFI 1.9.0 did the trick.

xentronium 13y ago
1.9.1 is yanked as of now, which means no one can install it accidentally.

jvoorhis 13y ago

This is disappointing. I've created a number of FFI-based projects, and maybe have taken it for granted. I checked the mailing list archives, and did not see any warning signs or calls for new maintainers.

petercooper 13y ago
This might explain some of it (not the original tweet but go much further down in the discussion with regards to how the licensing was changed): https://twitter.com/bascule/status/393509979711213568 https://twitter.com/bascule/status/393509979711213568

protomyth 13y ago

Does anyone have a clue of why? I looked, and the only weird thing I can see is the restoring of BSD license text to some files.

petercooper 13y ago
I wonder if this is related to there being an extensive "discussion" on Twitter a few days ago about ffi's LGPLv3 license. One thread to start from: https://twitter.com/bascule/status/393509979711213568 https://twitter.com/bascule/status/393509979711213568 .. one of the concerns much later in the discussion seems to be how ffi changed from BSD to LGPL at some stage.

nnq 13y ago

I never understood why aren't more Ruby extensions build on FFI instead of the MRI C extensions way - it would make everything work seamlessly on JRuby or Rubinius or Maglev and would also involve much less work. ...hope someone of the big Ruby backers take this project under their wing.

Argorak 13y ago

So after reading this commit: https://github.com/ffi/ffi/commit/346c80ad6b8c0e6dc3c390b582a81b306e1ef5f9 https://github.com/ffi/ffi/commit/346c80ad6b8c0e6dc3c390b582... and this discussion https://twitter.com/bascule/status/393509979711213568 https://twitter.com/bascule/status/393509979711213568 I have the impression that no one can safely fork ruby-ffi without opening himself to legal trouble. It seems like the licensing of the project is a horrible mess. IANAL, so I hope I am reading this wrong?

logn 13y ago
It's not that big of a deal. It's an LGPL-licensed codebase which incorporated BSD-licensed modules (there's nothing wrong with that). Since LGPL places some requirements on being intermingled with incompatibly-licensed software, the author made sure to point out which parts were under the more permissive BSD license so people could re-use those parts and not be subject to LGPL by using his project as a whole. In a nutshell, if you use an LGPL codebase, make sure either: (1) your code is LGPL or under a compatible license or (2) that you only use the code on an API level and dynamically link to it. Btw, LGPL is a license accepted by many enormous communities, such as Qt. If you want to fork this project, easiest route is to just re-apply the LGPL license and fork after the point where notice of BSD parts was added, because it's a violation of BSD to not mention their license. IANAL
- Argorak 13y ago
  I have no problem with the LGPL (beyond the occasional problem with legal, but thats legals problem) or the dual-licensing in general. The linked commit hints at additional problems with missing licensing etc. In the absence of good documentation on this, a new maintainer has the problem of not being able to make heads or tails of it if someone had claims on the code.
rtb 13y ago
I don't think that's the case. It appears to be LGPL + BSD. That should be fine for pretty much any use. "Postmodern" has it from the linked twitter thread: "they [are] probably confusing LGPL with GPL/AGPL, or are afraid of getting Stallman cooties."

izietto 13y ago

It's unfair that a so widespread project gets killed with so big lack of informations; FFI implementation is essential in every mature development platform IMHO.

ksec 13y ago

OH Great, another Project closed due to stupid and insane License argument and restriction.

yink 13y ago

Does anyone know the reason for closing this project? Wayne Meissner appears to have just protected his tweets https://twitter.com/wmeissner https://twitter.com/wmeissner

marti 13y ago

Ruby >= 1.9 also has a built in libffi wrapper, "Fiddle"[1], which can replicate basic Ruby-FFI functionality with some glue code[2]. There aren't many examples, but I've successfully used it to call Windows API (GDI+) functions. [1] http://ruby-doc.org/stdlib-2.0.0/libdoc/fiddle/rdoc/Fiddle.html http://ruby-doc.org/stdlib-2.0.0/libdoc/fiddle/rdoc/Fiddle.h... [2] http://www.slideshare.net/tenderlove/hidden-gems-of-ruby-19/134 http://www.slideshare.net/tenderlove/hidden-gems-of-ruby-19/...

rmoriz 13y ago
It would be awesome if someone can extend this and provide some kind of migration path for ruby-ffi users…

SmileyKeith 13y ago

That's definitely unfortunate. Seems like a lot of stuff I've done inadvertently requires ffi. And lately with Ruby 2.0.0-p247 on OS X Mavericks ffi 1.9.1 has been crashing..

username223 13y ago

As was said in the README: "The following people have submitted code, bug reports, or otherwide contributed to the success of this project:" But they can please to go die in a fire.

protomyth 13y ago

Here is a link to the "Cleaning up licensing" issue https://github.com/ffi/ffi/issues/288 https://github.com/ffi/ffi/issues/288