Difficult and inconvenience in working with ruby and bundle gems

Description

Here is an example of ruby folder structure

sam-app/ |-- api/ | |-- v1/ | | |-- endpoint.rb | | |-- helper.rb | | |-- helper2.rb |-- template.yaml |-- Gemfile |-- Gemfile.lock |-- vendor/ | |-- bundle/

endpoint.rb snippet:

require 'rubygems'
require 'bundler/setup'
require_relative 'helper'

def lambda_handler(event:, context:)
end

helper.rb snippet:

require_relative 'helper2'

helper2.rb snippet:

require 'some_legit_gem'

without using sam, pure ruby structure, it’s possible to run the code with command below

bundle install --path vendor/bundle
ruby app/v1/endpoint.rb

Steps to reproduce

bundle install # create vendor/bundle at root folder which is good
sam build
sam local start-api

Observed result

{
  "errorType": "Init\u003cLoadError\u003e",
  "errorMessage": "cannot load such file -- some_legit_gem",
  "stackTrace": [
    "/var/lang/lib/ruby/site_ruby/2.5.0/rubygems/core_ext/kernel_require.rb:54:in `require'",
    "/var/lang/lib/ruby/site_ruby/2.5.0/rubygems/core_ext/kernel_require.rb:54:in `require'",

Expected result

Doesn’t require vendor/bundle to be same level as actual lambda handler or provide a simple entry point to lookup vendor folder

Additional environment details (Ex: Windows, Mac, Amazon Linux etc)

1. OS: Mac OS 10.14.6
2. Sam CLI: 0.22.0:

[awood45]

Alternatively, you can sam build -m Gemfile from the root directory of your project and it should use the base directory Gemfile for all functions. Let me know if that helps in your case.

Closing for now as the base question is answered, feel free to reopen if you have further issues or questions.

[awood45]

So here’s the breakdown of what’s going on:

1. sam build looks in the CodeUri directory for the function given. This is useful in the case where different functions have different dependencies, to keep the overall artifact size down. So it will generally expect the Gemfile to be there, though workarounds exist.
2. The sam local issue where code changes aren’t reflected without building is a known issue and not Ruby specific - you’ve got the workaround and it’s in the feature backlog to have an easier path forward on this.
3. As for the possibility of multiple Gemfiles in a single project, as a longtime Rubyist myself I share that frustration. One approach if you have unit testing is to have your root Gemfile pull in the sub-Gemfiles, though I’m keeping my eye on projects like Gel as well which may have ways to support different dependency definitions for testing versus app dependencies. I’m actively pushing on these fronts.