Support Ruby 2.7 about rails-ex

[pvalena]

The ultimate solution would be to detect this "old Gemfile.lock" and update to new bundler using advised command. That can be either done with custom assemble scriplet (prepending the container one) or in the container's assemble script itself.

@hhorak @voxik WDYT? Should we bundle update --bundler in assemble on behalf of users app by default?

---

Note: there're two places (= assemble scripts) to solve this:

1. in s2i-ruby-container - the advantage being it's targeted for Ruby 2.7 solely
2. in custom assemble script added to this app

[yselkowitz]

FWIW doing this in s2i-ruby-container makes sense to me.

[hhorak]

@hhorak @voxik WDYT? Should we bundle update --bundler in assemble on behalf of users app by default?

I think Python container does something similar with pip as well, but not by default, only when UPGRADE_PIP_TO_LATEST is set (see https://github.com/sclorg/s2i-python-container/tree/master/3.8). I think updating it by default would be similar to the case we ship the upstream version, which is IMHO wrong from more reasons -- we nor users cannot control the version, upstream one can be broken, or changed too often... So, I'd personally prefer some bundler-alternative to UPGRADE_PIP_TO_LATEST.

[yselkowitz]

Correct me if I'm wrong, but there seems to be a difference. UPGRADE_PIP_TO_LATEST actually updates pip, which is already present in the container. OTOH AFAICS bundle update --bundler installs the gems specified in the Gemfile.lock and then updates BUNDLED WITH in the Gemfile.lock to the new version. Even when I locally reverted #128 and ran bundle update --bundler, the only difference to the Gemfile.lock was BUNDLED WITH.

Furthermore, there is a fundamental difference between Python and Ruby (gems), in that the latter supports multiple parallel installed versions, so the versions that ship with the gem will still be present. FWIW, in the case of rails-ex pre #128, only rake ended up with different versions than it started with, and the added version (which was actually older) did not clobber the preexisting version.

[voxik]

Wouldn't it be easier to just delete the Gemfile.lock and problem solved?

[voxik]

Wouldn't it be easier to just delete the Gemfile.lock and problem solved?

I mean delete from the repository. Its value is dubious for simple example app without any nonstandard dependencies.

[voxik]

Or is it question for any generic Ruby/Rails app? Then probably the env variable could make a sense.

[hhorak]

Wouldn't it be easier to just delete the Gemfile.lock and problem solved?

I think the reason for existence of this file is that the upstream projects were faulty sometimes and the Gemfile.lock was supposed to make sure the example application works the same always and OpenShift users don't see errors caused by changes in the upstream gem files. Maybe there is a middle way -- to specify version more exactly, but not using Gemfile.lock?

[voxik]

Or is it question for any generic Ruby/Rails app? Then probably the env variable could make a sense.

But then this is wrong place for this ticket and it should be discussed at https://github.com/sclorg/s2i-ruby-container/

[voxik]

Also, if the BUNDLED WITH\n 1.16.4 is dropped altogether, it will IMHO work independently of Bundler version.

[pvalena]

Wouldn't it be easier to just delete the Gemfile.lock and problem solved?

If we don't lock it CI tests may run into problems on upstream updates. That's why we have Gemfile.lock, to have reproducible results.

[pvalena]

@voxik or do you mean just the BUNDLED part... didn't think of that.

[voxik]

Wouldn't it be easier to just delete the Gemfile.lock and problem solved?

If we don't lock it CI tests may run into problems on upstream updates. That's why we have Gemfile.lock, to have reproducible results.

At least we would move forward with the dependencies ....

@voxik or do you mean just the BUNDLED part... didn't think of that.

Yes, I tested the removal with Bundler 2.1.4 and it worked unless I made some mistake.