Question: Drop support for rbczmq due to maintainability?

[rstammer]

Hi iruby-Team, I have a question - please excuse me if this question already has been discussed with a final statement - I just want to solve a practical issue.

Currently, iruby does support rbczmq, but I have the feeling that the project rbczmq is not maintained actively anymore.

Practically for my situation with iruby, there is a prioblem when I try to bundle iruby on macOS Mojave. It fails because rbczmq fails to build its native extension. I did some research on the problem and checked out zeromq/czmq as well as methodmissing/rbczmq.

I noticed that the latter contains czmq as a git submodule - but in a quite outdated (last commit from 2013) state. So the project czmq looks actively maintained, but not updated within rbczmq.

Also I noticed, that there are still open problems like methodmissing/rbczmq#41 which cause problems for iruby, too, see discussiom around #250

It's very hard to fix all the issues we need for iruby around methodmissing/rbczmq by ourselves - So my question to you is: Wouldn't it be a rational decision to drop support for it? Here's where I do not have deep knowledge, so please correct me if this question is more dumb. But since iruby supports multiple session adapters, I think the question is quite valid.

However, I know that such questions could be complicated. What consequences would it have, if iruby drops support for it? On the other side: What are consequences if rbczmq stays quite unmaintained for the next years?

Don't get me wrong, I do not want to offend the developers backing https://github.com/methodmissing/rbczmq, I know by myself how hard it is to find spare time to support such projects. It's really just about a practical decision. That's why I wanted to bring up the question.

Thanks for your patience, and I'm very curious about your thoughts!

edit: I've created a branch removing all references of rbczmq (just for myself as experiment)

[kojix2]

Hi @neumanrq

Thank you for your suggestion.

In short

I agree to stop supporting rbczmq.

Details

Around 2016, the current owner of IRuby @mrkn, suggested replacing rbczmq with cztop because rbczmq and ffi-rzmq were not well maintained. And @kou added cztop support (#106).
At the time, cztop was the first choice. There was an opinion that only cztop should be supported
(#128) .
But cztop update stopped about a year ago. The latest version of cztop has a problem installing Windows, but it will not be fixed (Gitlab cztop #17).

@mrkn tried using pycall and pyzmq, but this attempt is not complete (#221) . @kozo2 suggested using meta-kernel at sciruby-slack(JP). But no one actually tried to implement it.

Currently, ffi-rzmq is the first choice because it works very well. But It was not what I expected from the start.

Recently, there is a proposal to register iruby in conda-forge by @BoPeng (#235) with a related plan that ffi-rzmq should be added to rutime_dependency. (#248)

So I can not predict which libraries will continue to be maintained . But I think support for rbczmq will be stopped safely.

ping @mrkn

[mrkn]

@neumanrq Thank you for your suggestion.

I guess we will drop rbczmq support in the near future if the current situation of rbczmq is remaining. I want to do it but, the timing is not comming.

By the way, why you've tried to install rbczmq?
As far as I know, the latest iruby is usable without installing rbczmq.
You should be able to avoid the issue due to rbczmq by just stopping installing rbczmq and install ffi-czmq.
If not so, please tell us.

[rstammer]

Hi @kojix2 & @mrkn - thanks for providing all the background thoughts, which are very interesting!

@mrkn My initial goal was to learn how iruby works under the hood to see if I can implement some experimental stuff for myself with it (implementing a new plotting solution that employs ankane/chartkick).

So first I wanted to run the test suite and play with the code. But rbczmq, which is currently in the gem group test, prevented me from successful bundling, that was my entrance to this rabbit hole and I started researching.

If it's ok for you I'm going to try working on a sorted removal of references to rbczmq.

[mrkn]

@neumanrq Could you try rake docker:test? You can examine your experimental code on the same environment as CI.

[rstammer]

@mrkn Good tip! Unfortunately, by running rake docker:test or rake docker:build the script complains about a wrong bundler version (You must use Bundler 2 or greater with this lockfile.). I'm currently dabbling with the script to fix that locally for my machine, it looks like even I reinstall bundler within the script the container script is using the "wrong" bundler 🤔

[methodmissing]

As initial creator of rbczmq, I have not had cycles and bandwidth the last few years to maintain it and the divergence between current API and czmq (more so) and libzmq (less so) means a significant time investment is required just for parity. I have ongoing business and family obligations that does not allow me to dedicate time to rbczmq.

About methodmissing/rbczmq#70 , I have no objection to redirecting my Github project to https://github.com/Seluxit/rbczmq , but allowing gem pushes to rbczmq I cannot do due to security implications of handing over ownership of a contract (a gem definition in a Gemfile perhaps) that existing applications have, despite rbczmq not currently being maintained. Namespacing the gem is an option for a way forward though. As in release as seluxit-rbczmq (or similar, there's many better names) to rubygems and pull it into iruby in that manner.

I looked at the ruby bindings ecosystem and would agree it's not looking good given most are not maintained anymore. Which in itself is fine too because they came to life as OSS and were pinned to someone's free time at a given window of time. I do however still feel and agree that wrapping the czmq API makes the most sense as it covers some edge cases with the raw libzmq API natively.

[rstammer]

This has been done recently, see also #260