Provide .zip or .tar.gz along with 7zip archives?

[asottile]

I'm looking to write a utility for setting up ruby environments.

Non-free 7zip is a bit of a barrier-to-entry.

Would it be possible to provide something easier to extract such as .tar.gz or .zip?

[Azolo]

7zip is actually Free and Open Source; licensed under the LGPL.

If you look through the config directories you can find the download link to the 7za.exe executable that we use.

[asottile]

In that case, I'd like to be able to extract archives without additional dependencies (I'd rather not introduce subprocess dependencies). zip and tar both have much better support, especially out of the box and in the language I'm targetting (python).

[Azolo]

The choice to use 7z was practical as well as functional.

If you would like zip archives a PR would be welcome, but there are multiple ways to unzip 7z files, since it's based on lzma, but all of them do introduce some kind of dependency. (Though some distributions may ship with a lzma library)

You could also just as easily figure out how to run the installer unattended for similar results.

[asottile]

Could you point me in the right direction as to where I would add such a thing?

[Azolo]

@asottile You can try looking at https://www.joachim-bauch.de/projects/pylzma/

[asottile]

Oh I meant to start crafting a PR to add .zip

[asottile]

@Azolo Ping! Where should I start looking to add .zip support? I'd like to write a PR but I'm rather unfamiliar with the repository

[Azolo]

@asottile Look at https://github.com/oneclick/rubyinstaller/blob/master/recipes/packager/inno.rake

[dmajkic]

@Azolo, @asottile Inno based installer can silently install into location. Something like this:

rubyinstaller-X.Y.Z.exe /VERYSILENT /SUPPRESSMSGBOXES /NOICONS /SP- /DIR="C:\some_ruby_dir"

[asottile]

I understand I can run arbitrary executables to do this but I'd rather have archives that I can extract without having to do so. Can you point me in the direction so I can add zip archives to the artifacts you provide?

[Azolo]

@asottile All of the interpreter packages are created from the rake tasks in inno.rake.

However, the solution from @dmajkic is perfect in my opinion. It prevents any extra burden on me as a maintainer and you as an implementer by using already available functionality.

In this case, I feel like you're being dogmatic in your approach. My recommendations are basically this:
If you don't want to shell out to an executable of any kind, then include an lzma dependency. If you don't want to include any extra dependencies, then silent install using the above method. If you don't want to shell out or include extra dependencies, then writing a new packaging pipeline would probably be easier than extending RubyInstaller's.

[asottile]

I'm still baffled why there's so much resistance to adding a more widely supported archive format. Is there an actual reason 7zip was chosen? I guess more importantly for what I care about is there an actual reason why not also zip?

The reason I'm being so "dogmatic" as you put it:

• lzma doesn't have good python2 + python3 support (or even a pip package!) so it is not suitable for the platforms I target
• my primary platform I target isn't even windows to begin with so anything that complicates packaging / dependencies is already really unfortunate (not a real reason: fair)
• I really just want the ruby interpreter -- there aren't really any other providers which have downloadable prebuilt interpreters which is why I came here at all
• If I can avoid dependencies that greatly reduces the barrier to entry for my target users. The entire reason I'm doing this work at all is I don't want people to have to install $N tools (a C compiler, etc.). The zip format is extractable on every windows box going back to XP. .tar.gz is supported by any python installation (since python2.6). Both of those are zero-dependency choices for my targets. In order to support 7zip archives I'd have to worry about whether or not my consumers have installed 7zip or I'd have to use liblzma which would again require a C compiler.

This has been a really unfortunate and impolite exchange. I feel like the things I'm asking for aren't unreasonable and yet my questions have been avoided, my requirements dismissed, and this issue closed aggressively without solution and with action items still open.

I'll look into inno.rake, thanks.

[Azolo]

I'm sorry it came off that way. I don't mean to be unwelcoming. I'll try to address parts of my concerns and your questions.

is there an actual reason why not also zip?

I understand where you're coming from, but I would rather try to solve the problem in a way that doesn't increase my workload. So when introducing something like a new format I have to consider what that means for the release workload, that's the resistance you're finding.

lzma doesn't have good python2 + python3 support (or even a pip package!) so it is not suitable for the platforms I target

Ruby doesn't either, we shell out to the 7za executable.

..., my requirements dismissed, ...

I guess I don't understand your requirements other than the fact you would like a zip file distribution. Which we don't have. So we tried to come up with alternatives, which involved shelling out to external executables. In the ruby world shelling out to executables isn't just common, in a lot of cases it's encouraged. So, my original suggestion was to just download 7za or bundle it then shell out to it. I can accept that isn't something you would want to do because it's an external dependency. But with @dmajkic's suggestion you don't need that external dependency. That's where my dogmatic comment comes from. The silent installation solves the same problem as a zip distribution from my point-of-view.

I'll look into inno.rake, thanks.

I glanced through the recipes and it didn't look like it wouldn't be super easy to add something like a zip option without some major refactoring. Using something like Bintray you could probably much more easily create a pipeline to use 7z and rezip and upload it.

Is there an actual reason 7zip was chosen?

The reason why lzma/7z is used is because of the devkit. Here are the stats for mingw64-64-4.7.2:

• uncompressed: ~400 MB
• zip archive: ~150 MB
• lmza/7z: 48 MB

When files were hosted on a CDN and not BinTray this was significant. As an aside, we shell out to the 7za executable to do all of this.

The entire reason I'm doing this work at all is I don't want people to have to install $N tools (a C compiler, etc.).

This is something that you have to do in Ruby(The DevKit), and the reason why RubyInstaller builds are repackaged in all-in-one packages like RailsInstaller.

All of this being said, I would still consider a PR but I was a lot more open about it before @dmajkic's silent install trick. There would need to be a compelling reason that other solutions didn't work for me to consider adding release overhead.

[asottile]

fwiw unlike ruby, in python it's strongly discouraged to shell out (especially on windows where the subprocess cost is so high) which is the main reason I'm trying to avoid it.

What part of the release becomes more complicated - if possible I can try and reduce that burden if it's some script that needs updating, tests, etc.

[Azolo]

fwiw unlike ruby, in python it's strongly discouraged to shell out (especially on windows where the subprocess cost is so high) which is the main reason I'm trying to avoid it.

What's the cost in a one time shell out that saves you time and accomplishes the goal besides the fact you don't want to? It's ok to be weary of something, but you're already executing a bunch of high cost commands. Likewise, the cost of creating a process is still milliseconds, it probably takes longer to establish a tcp connection.

What part of the release becomes more complicated - if possible I can try and reduce that burden if it's some script that needs updating, tests, etc.

Uploading the files, updating the site, writing the release notes, getting the md5 and sha256 digests, and handling the BinTray manual steps. The big one is the website where an extra 2 files would probably increase the workload by about 2-3 minutes. So if there were 3 or 4 releases at once it would be an extra ~15 minutes of my time total.

The release notes may be able to be templated, but some things change. The md5 and sha256 digests are already generated as files and I use PowerShell to get the contents collect them and copy/paste them where they need to go. But without a major rewrite the website is still manual updates and the Bintray stuff is manual as well.

But, once again, even if you opened a PR you need another compelling reason for me to maintain code for another release format other than the fact you aren't willing shell out to another executable.

I know this reply seems like I'm dismissing you, but we're still talking about it and I'm all but pleading with you to use accepted solutions to solved problems. If there were obstacles to being able to use these solutions or this was a frequently requested item then it would be much easier to convince me,