Fix GEM_PATH to use correct Ruby installation

[mhart]

Hmmm, so these paths were set based on what /var/runtime/bootstrap does in a live Lambda, which is:

#!/usr/bin/env bash

if [ -z "$GEM_HOME" ]; then
    export GEM_HOME=/var/runtime
fi

if [ -z "$GEM_PATH" ]; then
    export GEM_PATH=/var/task/vendor/bundle/ruby/2.5.0:/opt/ruby/gems/2.5.0
fi

if [ -z "$AWS_EXECUTION_ENV" ]; then
    export AWS_EXECUTION_ENV=AWS_Lambda_ruby2.5
fi

if [ -z "$RUBYLIB" ]; then
    export RUBYLIB=/var/task:/var/runtime/lib:/opt/ruby/lib
else
    export RUBYLIB=/var/task:/var/runtime/lib:$RUBYLIB
fi

export PATH=/var/lang/bin:$PATH

[mhart]

Does rake run in a live (production) Lambda?

[dlahn]

It's not in the production version. Something weird is going on with the Ruby in the build container though. We are trying to use the following Dockerfile, and it fails to find the rake executable:

FROM lambci/lambda:build-ruby2.7

RUN yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
RUN yum install -y https://apache.bintray.com/arrow/centos/7/apache-arrow-release-latest.rpm
RUN yum install -y --enablerepo=epel parquet-glib-devel

COPY Gemfile Gemfile
COPY Gemfile.lock Gemfile.lock

RUN bundle install --deployment

Gemfile

source 'https://rubygems.org'

gem 'red-parquet'

Gemfile.lock

GEM
  remote: https://rubygems.org/
  specs:
    extpp (0.0.8)
    gio2 (3.4.1)
      gobject-introspection (= 3.4.1)
    glib2 (3.4.1)
      native-package-installer (>= 1.0.3)
      pkg-config (>= 1.3.5)
    gobject-introspection (3.4.1)
      glib2 (= 3.4.1)
    native-package-installer (1.0.9)
    pkg-config (1.4.1)
    red-arrow (0.17.0)
      extpp (>= 0.0.7)
      gio2 (>= 3.3.6)
      native-package-installer
      pkg-config
    red-parquet (0.17.0)
      red-arrow (= 0.17.0)

PLATFORMS
  ruby

DEPENDENCIES
  red-parquet

BUNDLED WITH
   2.1.4

Gem::Ext::BuildError: ERROR: Failed to build gem native extension.

current directory:
/var/task/vendor/bundle/ruby/2.7.0/gems/red-parquet-0.17.0/dependency-check
rake
RUBYARCHDIR\=/var/task/vendor/bundle/ruby/2.7.0/extensions/x86_64-linux/2.7.0/red-parquet-0.17.0
RUBYLIBDIR\=/var/task/vendor/bundle/ruby/2.7.0/extensions/x86_64-linux/2.7.0/red-parquet-0.17.0
/var/lang/lib/ruby/2.7.0/rubygems.rb:275:in `find_spec_for_exe': can't find gem
rake (>= 0.a) with executable rake (Gem::GemNotFoundException)
    from /var/lang/lib/ruby/2.7.0/rubygems.rb:294:in `activate_bin_path'
    from /var/lang/bin/rake:23:in `<main>'

rake failed, exit code 1

Any ideas?

[mhart]

It is in the production version – the ruby2.5 image is a direct copy of the production Lambda environment, with nothing added

[mhart]

Best solution for build images might just be to append the /var/lang/lib path, instead of replacing the /opt path (which is used for layers)

[dlahn]

This is 2.7. Is it different in this case?

[mhart]

Pretty sure it's the same on 2.7:

$ docker run --rm --entrypoint ls lambci/lambda:ruby2.7 /var/lang/lib/ruby/gems/2.7.0/gems
bundler-2.1.4
irb-1.2.3
minitest-5.13.0
net-telnet-0.2.0
power_assert-1.1.7
racc-1.4.16
rake-13.0.1
rdoc-6.2.1
test-unit-3.3.4
xmlrpc-0.3.0

[mhart]

So if you list /var/lang/lib/ruby/gems/2.7.0/gems on a production Lambda you should see the same results – ie, rake is there

[mhart]

Got this in at https://github.com/lambci/docker-lambda/commit/efbb6a296f9cd7c5a84bf01b254d12b0f727d684 and have pushed up the latest ruby build images – thanks for the contribution!

I also added the /opt path back in so that ppl can still build with layers attached