setup-ruby-pkgs

[MSP-Greg]

@eregon @ioquatix

I've got a start on a package install action. Works with ruby/openssl & puma, probably check psych next.

Still have more work to do on the Windows side, more inputs, gcc issues with older Rubies, etc. The gcc issue is actually with older patch/teeny versions. like 2.4.3 or 2.5.2. If one uses 2.4, 2.5, & 2.6, all is okay.

Being a Windows/MRI type, need help with other platforms/OS's...

I could care less where the repo lives, I just think a 'package' companion to setup-ruby is needed.

[ioquatix]

Even if we just get a few standard packages working cross platform, it's a great way for other packages to support testing windows and linux etc.

[MSP-Greg]

Does the 'package' concept exist for JRuby or TruffleRuby? I've run jruby-head locally, but that's about the extent of it...

[eregon]

No, there is no package for JRuby, TruffleRuby, just as there isn't for MRI. Ruby has gems, not packages. Only operating systems have packages, isn't it?

[eregon]

Thank you for creating this :)

[MSP-Greg]

No, there is no package for JRuby, TruffleRuby, just as there isn't for MRI.

Well, until you come up with a better name, we'll use the term packages. How are brew or pacman normally described?

Anyway, previously I've mentioned that any action like this needs to follow Ruby version selection/installation.

Now that we've got multiple Ruby platforms supported on OS's, that need is a little more clear.

An example would be Puma. It needs ragel for any MRI Ruby. But, it also tests JRuby. So, we can't determine whether to install ragel without knowing whether the job's Ruby is MRI or not.

Also, please consider whether the idea here should be included with setup-ruby.

With this separate, Puma would be:

- name: load ruby
  uses: ruby/setup-ruby@v1
  with:
    ruby-version: ${{ matrix.ruby }}

- name: setup compile tools, ragel, openssl
  uses: MSP-Greg/setup-ruby-pkgs@v1
  with:
    apt-get: ragel
    brew: ragel
    mingw: _upgrade_ openssl ragel

With this part of sertup-ruby@v2:

- name: load ruby & build dependencies
  uses: ruby/setup-ruby@v2
  with:
    ruby-version: ${{ matrix.ruby }}
    apt-get: ragel
    brew: ragel
    mingw: _upgrade_ openssl ragel

Personally, I think the 2nd version is much better. If there are no build dependencies, it is identical to v1...

[eregon]

I think ragel should be installed for Puma no matter what the Ruby implementation is. All will need it.

openssl is the one case a bit special for MRI where you'd want to match the version against which MRI was compiled. For other packages there is probably only one version of a package available on the system, so there is no choice. For TruffleRuby libssl-dev should be installed, and there is no Windows version so the system version is the matching one (typically true on non-Windows). For JRuby you probably don't need to install openssl, but it most likely doesn't hurt either.

My point is: if we install a dependency for MRI, it should be installed for other Rubies too, because they will most likely need it too (e.g., some C extensions requires it). Maybe JRuby is a bit special here in that most system dependencies are not needed, but e.g. native libraries to interact with FFI would still be needed.

If for some reason some package isn't needed with some ruby, people can always use if: startsWith(matrix.ruby, "ruby"), but I expect that's quite rare. I wouldn't try to magically guess which packages are needed or not on other Rubies, just install the same packages as on MRI, and use public Ruby APIs to find the versions you need.

[eregon]

Well, until you come up with a better name, we'll use the term packages. How are brew or pacman normally described?

I just meant the concept of packages here ("operating system packages") is IMHO completely independent from the Ruby implementation.

[eregon]

Re _upgrade_, I think apt-get upgrade/brew upgrade are almost never done in CI, they likely take way too long. And people typically want to ensure their software works on a fresh installation of that OS works fine, not necessarily with all the latest updates. It doesn't hurt to have that ability of course, just this is a bit of a difference where it seems more common to upgrade MSYS2.

[MSP-Greg]

While thinking about the conflicting issues of not wanting to add package inputs to setup-ruby, but also wanting setup-ruby-pkgs not having to be a separate step, I looked at using setup-ruby's util/index.js in setup-ruby-pkgs.

With a simple change, it works. IOW, with the change, setup-ruby works identical to how it now works, and setup-ruby-pkgs uses the code from setup-ruby to install the Ruby binary. Or, if one doesn't need any packages, one uses setup-ruby. If one does, one uses setup-ruby-pkgs.

Interested?

[MSP-Greg]

I released 1.0.0.

JFYI, I'm using it to set the mingw & mswin master builds on Actions.