stop using fork, which means JRuby support #148
Conversation
|
@nadarei any plans to merge this? as of current master jruby support is still broken |
|
👍 |
|
+1 for this |
|
👍 |
|
I wasted half a day configuring mina for our project only to discover "fork is not available on this platform" Please merge this 👍 |
|
just install as system gem for system ruby(it's often MRI isn't it?) and use, there no need for deployer to wait JVM to boot and run deploy script, it isn't fast. |
|
@kucaahbe true that, however it's cumbersome to switch rubies every time I want to deploy. It kind of beats the purpose of automatic deploy if I have to do some stuff by hand to make it work. Also, given modern hardware and tools, JVM boot time is rarely an argument. (even on my laptop) |
|
@kucaahbe that's not a valid argument, especially when the fix is so trivial. |
|
@mrbrdo " I never install a system ruby"- on most linux distributions and OSX there already pre-installed ruby(mri) as dependency and disinclination to install ruby isn't enough argument than supporting one more interpreter, take a look at travis build, there already 6 builds and lack of 2.x.x, and you want author to mess with jruby just because you just want and you fix is (currently) trivial? In any case I hope maintainer will read this and take into account. @alisnic - no need to do that, any gem already know which interpreter to use on adequate installations. Also this simple wrapper could be used: https://gist.github.com/kucaahbe/9324386. We use it (project itself on jruby) and we happy. |
|
@kucaahbe I don't agree with you and I see no reason not to support JRuby at this point. I provided a pull request and I don't see a reason not to merge it, there is no JRuby specific code in it, it just uses threads instead of fork. If it comes to a point where supporting JRuby is a problem, support can be dropped at that point, but at the moment I don't see a reason not to support it. Not accommodating a change like that just because "XY interpreter support might break anyway some time in the future" is ridiculous. The threading solution is also more efficient and makes more sense than forking. So regardless of the fact that it also works on JRuby it should probably be merged. |
|
@mrbrdo You misunderstood me, I don't see any issues with code, furthermore I agree that threading could be more efficient than forking, my point that there no reason to explicitly support jruby as there much simpler and native way to use gem. After bundler ruby people forget about what |
|
@kucaahbe it might not matter for your setup, but it matters for mine. It introduces a dependency that I neither want nor need. Also I do not like your argument at all, how would you feel if I made a gem that only worked on rubinius and then told you that there is no reason for me to support MRI since you can use rvm or rbenv and use my gem with rubinius, even if you use MRI on your project. And especially when the gem is not doing anything that would make it hard or inconvenient to add support. I understand some gems depend heavily on C extensions or really need fork, but here this is simply not the case. |
|
@mrbrdo If I you create some good solution that will work only in rubinius I'll install rubinius, because I can and think in terms of solving project's problems. |
|
It's your opinion. If you want to express it go to a forum or mailing list, this is not the place for it. |
|
Just keep to the point. And anyway, it doesn't really seem like maintainer is active for this project anymore, so I doubt we will accomplish anything. |
|
Will this still work on MRI? |
|
Of course it will, MRI supports threads |
|
@rstacruz I'm also for this, what do you think? |
|
...let's do it and release 0.4.0 soon. this is swell. |
stop using fork, which means JRuby support
#147