Provide RubyInstaller with builtin MSYS2 toolchain #42
Conversation
This is RubyInstaller plus up-to-date MSYS2 environment.
Otherwise it fails to run in build environment when the build runs without RubyInstaller2 runtime libraries.
Use external pacman cache for devtools as well.
They are not supported but slows down the build.
C:/ri2-ruby/lib/ruby/site_ruby/2.4.0/ruby_installer/runtime/msys2_installation.rb:27: warning: instance variable @msys_path_fixed not initialized
|
@luislavena @jonforums @Azolo @MSP-Greg Any opinions to adding this? |
|
DevKit was originally separate because it was possible to have multiple Ruby installations use the same DevKit "installation". In retrospect, having a package like this isn't a terrible idea. But, it is another thing to maintain and another spot for confusion. I would make sure you have a suggested installation package and explain the differences. But, that's just my pessimistic outlook and suggestions based on that outlook. Don't feel bad for not putting too much weight on my advice. |
|
@larskanis @Azolo Sorry for the delay. I'm somewhat conflicted about embedding MSYS2 in the ruby dir structure. I've spent decades working with DOS/Windows, and probably weeks working on OSX. So I understand the 'oneclick install` mentality, which is tricky to provide for extension gems. I wonder if it will cause confusion for users when/if they decide to upgrade ruby. I can't help but think that new Windows ruby users fall largely in two groups. The first, people with some programming experience that would understand the issues. The second, new users learning programming, and probably also installing Rails. If anything, I think a package that supplies most of (or all?) the MSYS2/MinGW files needed for a Rails install might be one for consideration... Sorry for going sideways... |
It is now in a separate repository.
…our ruby installation
bundler modifies the PATH which interferes with our expectations to enable_msys_apps and disable_msys_apps. In particular: Bundler removes dups in the PATH, with the result, that disable_msys_apps removes Ruby's bin entirely from the PATH.
This way it can be used for a different MSYS destination than the one that is running.
Otherwise MSYS tools installed per 'ridk install dev_tools' can depend on newer libraries than these delivered in the MSYS2 base package. In particular current gawk depends on msys-readline7.dll , but the base image version is still msys-readline6.dll . Therefore gawk fails to execute.
These files are re-created on the target system.
larskanis
force-pushed
the
rubybundle
branch
4 times, most recently
from
8270a94 to
6e71971
Compare
…pository Sources are located here: https://github.com/oneclick/rubyinstaller2-packages The signed repository is stored on bintray: https://dl.bintray.com/larskanis/rubyinstaller2-packages Add ruby-2.5.0-snapshot build target.
Fixes install issue on i686.
sandbox This should avoid interferences.
Fixes nokogiri test build on i686.
|
Thanks for sharing your thoughts! In the last two days I resurrected the idea of having a installer package with all default MSYS2 dependencies. It's because I need it at work, so that I would like to make it "official". If you like, you can try it out from Appveyor artifacts.
This was the main technical issue I had to solve. How shall updating MSYS2 work, if it's bundled into the installer? I think it's mostly solved now: MSYS2 is handled as a selectable component, which is automatically deselected on an update install with MSYS2 already present. MSYS2 is decoupled more or less from Ruby after installation, so that it can be updated separately by
This is true. It is a second way to install MSYS2, but the current way through
For sure, that should be the case for typical rails apps! Otherwise I would tread it as a bug. I don't try to support each and every possible gem, but the most typical gems should just work. My plan is to post about RubyBundle on rubyinstaller.org as an experimental feature and if it works well, to add it to every future release. |
|
I think this may solve a lot of issues for people with new installs. The only issue I came across recently was working on Appveyor with a gem that used OpenSSL, and was testing against both 2.4 (1.0.2) & 2.5/trunk (1.1.0). Maybe docs/install 'info' could include some info about it? I think (at present) OpenSSL is the only package that may cause issues? I worked around it, but for those less familiar... Thanks again, Greg |
Which gem is it? Is it about issue #60? What should be documented? |
|
@luislavena @jonforums @Azolo @MSP-Greg @Kjarrigan Do you have an opinion about the name of the new baby with builtin MSYS2 toolchain component? Both installer variants are still the same, with the only difference that one has a selectable install component called "MSYS2 development toolchain" and the other doesn't. Both can be mixed and matched at will. So my proposals are:
What do you think? |
|
I vote 3, as to 'MSYS2' or 'DevKit', that's a tough choice. I'm not sure how well known the term 'MSYS2' is outside of people that have used it. then again, maybe people should be familiar with it. Also, having used Notepad++ for a while, rather than '-with-devkit', maybe use '+devkit' (or MSYS2)? |
Sorry for the delay, I thought I knew of three, but I have not remembered the third. The two are EventMachine & Puma. I assume that if one is using 2.4, they should be compiled with 1.0.2, if one is using 2.5, 1.1.0 should be used. I haven't actually used the exe installer for quite a while, so I don't know if it accounts for this FYI, new OpenSSL releases on Tuesday. Thanks, Greg |
|
@larskanis Honestly, if you want it to be the default then just name it Name the installer without the tool chain something like Not every one will be happy, but if it's what you want then do it. It's not like you can't change it if it doesn't work out. |
|
I'm for option 3 as well. Its more clear than the rest but I agree to Azolo as well. Just make it the default and add an Rubyinstaller-without-Devkit as opt-out. I think the most people looking for Rubyinstaller have eiter no clue what the Devkit-thingy is, but experience rather quickly problems when installing gems that depend on it, or they know what it is and are able to decide if they might reuse an existing msys setup. In all the years I installed Ruby under Windows (which wasn't that often but) I always needed the DevKit and usually it was annoying the do two setups to just get Ruby running so I could continue installing my gems. |
As discussed in PR #42 . This shortens the package directory names to ri and ri-msys because InnoSetup fails otherwise to find iss files due to Windows MAX_PATH limitations to 260 characters. The name ri+msys doesn't work as a rake task, so that ri-msys is used there.
|
Thanks again for discussing the naming issue! As you can see in the release post, I stepped forward and published the RubyInstaller-Devkit versions together with the new Ruby versions 2.5.1 and 2.4.4. Plus character didn't work, so that I kept backward compatibility by using Keep fingers crossed for that it works for everyone! |
This adds a second package called "rubybundle" which exports ~100MB sized exe and 7z files. See the artifacts on Appveyor. This avoids extra download and setup of MSYS2 for the user and could be interesting for offline installations.
I'm not sure about the name "rubybundle". Has someone a better name?
Although it already works well for me, it probably needs some more fine tuning. It currently ships a fully arranged MSYS2 environment with private keys. They should be better generated on the target machine.