multiSnow
commented
3 years ago I could not point out any benefit to support unar, such a 'swiss knife' depends on gnustep runtime and object-c runtime and ICU and wavpack for only rar archive 'in theory', while the unrar/libunrar, provided by that RARLAB together with source code, which only depend on C++, could certainly deal with all rar archive no matter the version or type or encryption. Also, I could not understand why it is so important to strictly use a free software to support a non-free format.
IMHO: 1, for the user, extract that rar archive book by your favorite toolkit and, if you still want it to be a single file, pack into zip or tar, which should be best supported by python; 2, for the maintainer of the linux distribution that refusing any non-free software, just create a patch and be proud of that. all APIs already exist there.
Additionally, there is already another 'free' method in mcomix3, by using 'archivemount', which is only used for tar for now but should also 'in theory' support rar archive. The outstanding advantage of using this method is that it almostly needs no space to cache anything. Also, as I mention 'archivemount', the libarchive is another 'swiss knife' to deal with archive. I may rather using this library through ctypes than analyzing the human-readable stdout of a commend-line tool by writing dozens of regular expression, for performance reason.
unar has the ability to open rar files.
If it's rar version 3.0 or bellow, it will actually use internally unrar-free. For 4 and 5 it uses it's own reverse engineered code. In theory, it's fully compatible.
If unrar is not present, mcomix should try with unar.