Mojo::IOLoop::ForkCall deprecated, use Mojo::IOLoop::Subprocess instead

[ahesford]

I'm looking to package znapzend for Void Linux, but found that Mojo::IOLoop::ForkCall is marked deprecated by the maintainer. The preferred replacement is Mojo::IOLoop::Subprocess, built right into Mojolicious.

A quick review of znapzend and the Mojo::IOLoop::Subprocess documentation leads me to believe that moving to the preferred replacment is as simple as s/ForkCall/Subprocess/ in lib/ZnapZend.pm and lib/ZnapZend/ZFS.pm, but I am neither a very sophisticated Perl hacker nor terribly familiar with znapzend.

[jberger]

I'm the maintainer of the module in question: (a) yes usually changing the module name is that easy, there are some slight differences especially if you are using the events it emits, but for simple usage it is an easy port and (b) I'm not going to delete it from CPAN any time in the near future. Worst case is it gets less maintenance than I'd normally do. Certainly you should port it so that you get better support from Mojo core but don't fear that I'm going to intentionally cause outages.

[oetiker]

@ahesford will certainly be updating to the new subprocess approach ... but for now, you can just continue using it as is.

[ahesford]

Thank you both for your responses. I am not currently using znapsend but thought I might explore while creating a Void package. Void is also missing a couple of dependencies, including Mojo::IOLoop::ForkCall. Adding a new package for a Perl module labeled deprecated, even knowing that it will persist indefinitely, may raise some eyebrows with the rest of the Void team. This is a back-burner issue for me, so I might let things sit for awhile and reevaluate when interest or necessity demands.

[jimklimov]

Just in case, is this new method introduced recently? A bit back I did have to amend the configure script (and requirements file) to require an older Mojolicious version if running with perl-5.10 for example.

Being quite cross-platform, including Solaris 10 systems still running, znapzend has to support quite a wide range of perl versions and dependencies, at least if that is not prohibitively hard to maintain. Probably this does not mean that an obsolete implementation must remain the only one used - especially if like in this case it is a simple replacement, than some variable for function name, or a wrapper function making the choice, can suffice. And of course an optional include of new dependency, with fallback to old one.

[oetiker]

subprocess has been around for quite some time ...

[cgaspar]

FYI, this has broken the spike repo znapzend RPM on Fedora 33, as there is no longer a perl-Mojo-IOLoop-ForkCall RPM available :-(

[jberger]

Unfortunately system packagers rarely if ever communicate with upstream library authors. I was neither aware that there had been an rpm for it nor that it no longer had one. Personally I always recommend getting your CPAN dependencies from CPAN. Distro packagers do a service, but not one that we CPAN authors can control or even see.

[spike77453]

FYI, this has broken the spike repo znapzend RPM on Fedora 33, as there is no longer a perl-Mojo-IOLoop-ForkCall RPM available :-(

Sorry about that, it should be fixed now.

[ahesford]

Closing because I'm not really thinking about this anymore.