Support `.rar`

[c02y]

https://crates.io/crates/rar

[figsoda]

This crate seems to be unmaintained, is there other alternatives?

[vrmiguel]

RAR is a proprietary format so we'd only be able to decompress those (unrar is open source) but that sets a weird precedent since all other supported formats can be compressed and decompressed through ouch alone

@marcospb19 @GabrielSimonetto @SpyrosRoum thoughts?

[SpyrosRoum]

Hm yeah that would be weird. We could spawn a command to handle compressing it but that would introduce a runtime dependency and would also be different from the rest. If we do that it might be worth locking it behind a feature flag as an extra warning

[marcospb19]

I don't think we should support .rar because, unfortunately, we can't compress and decompress it reliably yet, and I don't think we will any time soon.

About spawning commands for external binaries, that may add a surprising amount of complexity for shipping, implementation and testing, making it even harder for people to contribute to our tool.

Also, it's possible that we would need to parse the STDERR output of the command to fit messages to our error treatment system, I wouldn't be surprised if this caused bugs.

If we cannot guarantee the quality of a feature, maybe the best decision is to skip it.

That's just my POV tho, if we get a nice crate for this and everybody agrees, we can add it.

[sigmaSd]

Personally I think we should support tar and external binaries in general, because the way I see it is ouch wants to:

• be simple to use
• be the only compression/decompression tool that the user needs

If for each format that we don't support the user falls-back to another tool , it kind of defeat the second point

Also rar is not only the only common format we're missing, lzip for example is missing as well and there might be others

I think we can make a nice wrapper around all these tools that's clearly separated in its own module/crate and that exposes good api for ouch

Also when a native implementation arises we can just swap that

[sigmaSd]

Hmm archlinux doesn't seem to even have rar (only unrar), I guess I don't feel strongly about this now

[marcospb19]

be the only compression/decompression tool that the user needs

That's not exactly true, we knew from the start that we wouldn't be able to cover all compression formats because there are a lot of them out there, but we already support the most important ones, for example, to my personal use cases, ouch covers 100% of the formats I need (.tar.{zst, gz, xz} and .zip).

I'd also say we fulfill the needs of at least 80% of our users with the formats we currently support.

We could try to be like atool and deal with the dependency hell of calling binaries, but then, we wouldn't have control of what's being done, we can't encode and decode with io::{Write, Read}.

I guess the worst part is that some of our features (current and future) would have to be dropped, and behavior would turn inconsistent if we did it.

[llagerlof]

It's not like .rar it's an obscure compression format. It's widely used. If the goal of ouch is to make life easier for the users I think it should accept this format transparently for the end user, by any means necessary.

[marcospb19]

Yeah, not obscure because of its popularity for sure, but obscure because we cannot create a .rar archive. Fully supporting .rar seems impossible.

[llagerlof]

I mean, it's possible following @sigmaSd suggestions.

[figsoda]

I think it's ok to only support decompression for rar, however I don't want to call external binaries since it doesn't work with the streaming decompression that we currently have and that would also make ouch require runtime dependencies.

On the implementation side, I also found unrar which seems more maintained (recent commits in te repository, but no release since 2019). Something to take note of if you are trying to implementing this, @marcospb19 pointed out that there are different versions of the rar format (4 and 5) and the libraries don't necessarily have support for both of them.

@marcospb19 and I don't use rar and the implementation of this feature in ouch likely wouldn't happen any time soon without contributions due to our lack of motivation.

[marcospb19]

@llagerlof

I mean, it's possible following @sigmaSd suggestions.

:thinking: correct, but we aren't considering external binary dependencies because they ruin how Ouch works and breaks a couple of existing features we don't want to break.

+ if we add a binary dependency, we can't ship Ouch to Linux distributions, at least not with it working, we'd need to link our users to use AUR, PPA, or something else.

Yeah, that's a tiny problem, not a big deal, the big deal is the sum of all downsides involved in this.

---

Due to the requests, as @figsoda said, we are considering adding partial support for .rar (only unpacking), but without external binaries.

https://github.com/muja/unrar.rs might be a good one, we need to take a deeper look at it, but the sketchy license seems to be compatible with what we're doing.

---

be the only compression/decompression tool that the user needs

I believe we have a communication problem here, from our part (maintainers), of what Ouch aims to be, and it needs to be addressed, there are other tools that are meant to do exactly what you guys are looking for (be the one and only tool you need), and I expect them to do that even better than Ouch could possibly do.

If Ouch currently supports all formats you need, then you can just use it, which is the case for a lot of people, otherwise, there are tools that support everything by calling binaries, well, the UX is trash but that's what you get by committing to external binaries anyways.

We'll take the opportunity and solve this communication problem after #291. Ouch is not trying to reinvent the wheel for doing stuff other tools already do, there are better binary-call wrappers around.

---

Please don't be angry at me :sweat_smile:, this back-and-forth between maintainers and users on what a tool should be is inevitable in open-source and commonly end up in disagreements.

[marcospb19]

@marcospb19 and I don't use rar and the implementation of this feature in ouch likely wouldn't happen without contributions due to our lack of motivation.

Just to be clear, we didn't just added support for the formats that we wanted.

We tried creating a tool with streaming (de)compression between formats and good user usage, which could statically compile and had good error reporting capabilities.

Based on that, we added support for all formats that fitted and had a ready-to-use crate.

[roland-5]

As a user, I love that Ouch is a standalone binary without dependencies that I can just copy to a new machine and use, without thinking about it. I ditched atool and few other tools for Ouch because of it. It's not like that I don't have rar archives, because some sites still use them, so I still need to unpack them, but I just use unrar at moment like these. Even if a format may be (or was) popular, if its support affects the idea and construction core of the application, then supporting it does not make sense.

[poperigby]

[libarchive](https://libarchive.org/) might be something to look at in the future for a free software implementation of the RAR format.