Guide should describe how to set up a ruby gem

[KrauseFx]

I maintain 5 ruby gems, which could be delivered using Traveling Ruby for easier install.
Right now, it's quite a pain to adapt the Rakefile to make it work with a ruby gem:

I changed the following:

sh "cp Gemfile Gemfile.lock packaging/tmp/"

to

sh "cp Gemfile Gemfile.lock #{PACKAGE_NAME}.gemspec packaging/tmp/"

and

sh "cp hello.rb #{package_dir}/lib/app/"

to

sh "cp -R lib/* #{package_dir}/lib/app/"

Unfortunately I haven't yet got it to work, since I've got problems with the path:

[path]/[name]-0.1.0-osx/lib/app/[name].rb:2:in `require': cannot load such file -- [name]/version (LoadError)
    from [path]/[name]-0.1.0-osx/lib/app/[name].rb:2:in `<main>'

I'm pretty sure some things will change from time to time in the proposed Rakefile described in the guide. How should I keep up to date with the changes?

• I don't get to know when something changes, except when I actively watch the repository
• I have to re-apply my manual patches, change the name, version, remove the linux related code, etc.
• I think there are quite a lot of ruby gems, which can now be offered as one package, like the nomad tools and my open source tools.

Maybe I'm missing something here?

Traveling Ruby looks really promising, but is very hard to set up and maintain for me right now.

[FooBarWidget]

I'm pretty sure your problem is some load path issue, but I'm not sure what it is without taking a closer look at your app.

As for keeping your Rakefile up to date: you don't have to do that. The core idea is that you take our binaries and drop them in a package. If your Rakefile works, you never have to update it again. The Rakefile is also designed to be customized.

But I agree that it should be easier to create Traveling Ruby-based packages. We should have a tool that can automatically create a package, given a gemspec.

[KrauseFx]

I tried integrating into deliver. I'd like to get started for all my open source tools (linked on top of the README)

You think the Rakefile will never change? It looks like a lot of code, which might change in future versions of traveling-ruby

Have you tried setting up traveling-ruby for a gem? An example project would definitely be helpful for new users.

The load path problem is a result of moving the *.gemspec file into a subfolder.

Thanks for your help @FooBarWidget 👍

[FooBarWidget]

I do not say that our Rakefile will never change. I say that your Rakefile does not have to change.

[KrauseFx]

@FooBarWidget
This is what I came up with up until now: PEM Commit

What I did:

• I added a workaround to pass the gem version via an environment variable.
• I update the path: $LOAD_PATH.unshift File.expand_path('..', __FILE__)
• I copy over the executable from the bin folder: sh "cp bin/#{PACKAGE_NAME} #{package_dir}/pem_cli"

Problems I have:

• When running pem, I experience require exceptions, like this one: /pem-0.3.0-osx/lib/vendor/ruby/2.1.0/gems/websocket-driver-0.5.1/lib/websocket/driver.rb:22:inrequire': cannot load such file -- websocket_mask (LoadError)`. There still seems to be something wrong with the include path
• The CLI does not seem to work, I still have a pem file, additionally the original pem_cli, which uses commander
• Setting the version number like this is quite hacky

The full source can be found on the PEM GitHub Page in the traveling-ruby branch.

Thanks for creating traveling-ruby, I'm looking forward to get it up and running for my projects 👍

[blahah]

I solved this problem in my gems by just putting the contents of vendor into the app directory, so bundler can resolve paths properly for the gemspec to build. Any specific reason why this is bad idea?

[FloorD]

We're consolidating all issues concerning gems and gem support to work on in the next few weeks. Thank you for reporting this!

[Nowaker]

@FloorD We found the example Rakefile to be pretty annoying. sh "cp Gemfile Gemfile.lock packaging/tmp/" in a rake task makes no sense when all of that rake's task code is executing shell commands. A shell script is way cleaner than that. I replaced a 140-line Rakefile full of sh 'something' with a 60-line shell script. An added bonus is the script runs faster since it doesn't have to load rake, and stdout/stderr are natural.

Additionally, hardcording gem names inside the Rakefile isn't nice. Gemfile is the place where project dependencies and versions are to be defined. I came up with a way of marking gems as Traveling Ruby gems directly in Gemfile. This makes every developer aware of the fact a given gem is not to be messed with unless the version exists in Traveling Ruby. Moreover, an explicit Traveling Ruby gem has to have a version number defined. With this approach, all is clear, explicit and self-contained in Gemfile.

My work is below. It might not be a copy-and-paste replacement for one's Rakefile but the overall approach is way better than the original one. Hope this makes its way to the official Traveling Ruby.

#!/usr/bin/env bash
set -x
cd "$(dirname "$0")/.." # Start from webapp root

TARGET='linux-x86_64'
VERSION='20170106-2.3.3'
URL="https://OUROWNMIRROR/traveling-ruby/$VERSION"
PACKAGE_NAME='virtkick-webapp'

rm -rf packaging/tmp packaging/vendor
mkdir -p packaging/tmp packaging/tmp/engines packaging/vendor packaging/traveling
cp Gemfile packaging/tmp/

function copy_engine {
  if [[ -n "$1" && "$1" != 'basic' ]]; then
    cp -r "engines/$1" packaging/tmp/engines || exit 1
  fi
}

copy_engine "$MODULE"

(
  cd packaging/tmp && env BUNDLE_IGNORE_CONFIG=1 NOKOGIRI_USE_SYSTEM_LIBRARIES=1 PACKAGING=1 \
    bundle install -j20 --path ../vendor --without development test || exit 1
) || exit 1

rm -rf packaging/vendor/*/*/cache/*
rm -rf packaging/vendor/ruby/*/extensions
find packaging/vendor/ruby/*/gems -name '*.so' -exec rm -f {} \;
find packaging/vendor/ruby/*/gems -name '*.bundle' -exec rm -f {} \;

echo 'Downloading Traveling Ruby'
wget --quiet -c "${URL}/traveling-ruby-${TARGET}.tar.gz" -P packaging/traveling || exit 1

echo 'Copying webapp'
package_dir="${PACKAGE_NAME}-${TARGET}"
rm -rf "${package_dir}"
mkdir "${package_dir}"
mkdir -p "${package_dir}/lib/app"
cp -r config.ru Rakefile bin app config lib spec db frontend package.json "${package_dir}/lib/app/" || exit 1
rm -rf "${package_dir}/lib/app/vendor/cache" "${package_dir}"/lib/app/db/*.sqlite3 "${package_dir}/lib/app/config/database.yml"
mkdir "${package_dir}/lib/ruby"
tar -xzf "packaging/traveling/traveling-ruby-${TARGET}.tar.gz" -C "${package_dir}/lib/ruby" || exit 1
cp packaging/wrapper-common.sh "${package_dir}/lib" || exit 1
cp -pR packaging/vendor "${package_dir}/lib/" || exit 1
cp packaging/tmp/Gemfile packaging/tmp/Gemfile.lock "${package_dir}/lib/vendor/" || exit 1

rm -rf 'packaging/tmp'
mkdir "${package_dir}/lib/vendor/.bundle"
cp packaging/bundler-config "${package_dir}/lib/vendor/.bundle/config"

grep -F '# TravelingRuby' Gemfile | while read -r line; do
  GEM=$(echo "$line" | awk -F "'" "{print \$2}")
  GEM_VER=$(echo "$line" | awk -F "'" "/$GEM/ {print \$4}")
  echo "Downloading from Traveling Ruby: $GEM $GEM_VER"
  wget -c "${URL}/${GEM}-${GEM_VER}.tar.gz" -P packaging/traveling  || exit 1
  tar -xzf "packaging/traveling/${GEM}-${GEM_VER}.tar.gz" -C "${package_dir}/lib/vendor/ruby" || exit 1
done

gem 'rails'
gem 'whatever'

def traveling_ruby_gem name, version
  if ENV['UPDATE_GEMS']
    gem name
  else
    gem name, version
  end
end

# These require native extensions. Ensure Traveling Ruby provides an appropriate version before bumping.
# Traveling Ruby binaries are here: http://traveling-ruby.s3-us-west-2.amazonaws.com/list.html
# Do NOT remove a comment on their right! We grep for this comment in packaging/build.sh.
traveling_ruby_gem 'bcrypt', '3.1.11' # TravelingRuby
traveling_ruby_gem 'binding_of_caller', '0.7.2' # TravelingRuby