[LRUG] Rake binstub

Thu Oct 9 15:09:51 PDT 2014

bundler is a tool that makes sense when the app's contract is with the
filesystem. My suggestion doesn't imply less isolation, on the contrary.
12factors is great, it consolidates this type of contract and it also
allows to be substituted for a better one. After all, the whole 12factor
app concept was born at Heroku.

A Heroku app slug is linked against a specific stack, the most important
implication of this being the rootfs. This resolves the whole development
headers and C libs dependency hell which bundler doesn't help with. So an
app slug doesn't just address the "single version of the correct gem"
problem, it also satisfies the system requirements that those gems have.

The last bit of the "buildpack wizardry" comes in the form of a shell
profile fragment which has all the correct paths. This is an artefact of
the buildpack compilation phase and defines the paths to all
apps' dependencies explicitly. Whether one uses bundle exec or not,
using this shell profile fragment in the process environment guarantees
that it will only get the gem binaries & ruby binary specified in
the Gemfile. So, in the context of an app slug, bundle exec is redundant as
the shell environment used by all processes has all dependencies
resolved explicitly.

The same model depending on buildpacks and rootfs's is used by CloudFoundry
and other PaaS-es

, proof of its versatility. The reason why it works so well is because the
app contract becomes a kernel based one. Docker brings the same type of
kernel contracts to the masses, and everyone is all over it
(especially mature companies that understand their value in large-scale
production environments).

Gerhard

On Thursday, 9 October 2014, Stephen Best <bestie at gmail.com> wrote:

> Really good point Sam!
>
> I'm not sure what the virtue of removing the `cd` step from your cronjob
> is. It sounds way more trouble than it's worth. However this was
> interesting to think about the answers were great also.
>
> Gerhard - Not using `bundle exec` in production seems like introducing an
> unnecessary discrepancy between environments. I'm sure the core point
> you're making is that production servers should have no extraneous packages
> installed but I'm just not sure enforcing that by giving up isolation is a
> good thing.
>
>
> Stephen Best
>
> theaudaciouscodeexperiment.com
> github.com/bestie
> @thebestie
>
> On 9 October 2014 10:11, Sam Phippen <samphippen at googlemail.com> wrote:
>
>> I heard http://12factor.net/dependencies 12 factor apps were a pretty
>> good idea.
>>
>> On 8 Oct 2014, at 19:12, Gerhard Lazu <gerhard at lazu.co.uk> wrote:
>>
>> ... and by "bundle exec" I mean bundler/binstubs/rvm/rbenv/chruby, the
>> whole lot.
>>
>> On Wednesday, 8 October 2014, Gerhard Lazu <gerhard at lazu.co.uk> wrote:
>>
>>> bundle exec usage should stop at your CI/CD.
>>>
>>> Production should always have a single version of the correct dependency
>>> (whether it's the Ruby binary, gem or C extension).
>>>
>>> Heroku Ruby app slugs and CloudFoundry Ruby app droplets are good
>>> examples of this principle in practice.
>>>
>>> Gerhard
>>>
>>> On Wednesday, 8 October 2014, Andrew Stewart <boss at airbladesoftware.com>
>>> wrote:
>>>
>>>> Hello!
>>>>
>>>> For a long time I have had on my server a cronjob which runs a rake
>>>> task:
>>>>
>>>>     42 * * * * RAILS_ENV=production cd /path/to/my/app && bundle exec
>>>> rake blah
>>>>
>>>> Recently I decided to get with the program and use a binstub instead:
>>>>
>>>>     42 * * * * RAILS_ENV=production /path/to/my/app/bin/rake blah
>>>>
>>>> But it fails with: "rake aborted! No Rakefile found".  Naturally there
>>>> is a Rakefile at /path/to/my/app.
>>>>
>>>> My rake binstub is the one that comes with Rails 4:
>>>>
>>>>
>>>> https://github.com/rails/rails/commit/009873aec89a4b843b41accf616b42b7a9917ba8#diff-15
>>>>
>>>> – not the one that Bundler would generate:
>>>>
>>>>     #!/usr/bin/env ruby
>>>>     #
>>>>     # This file was generated by Bundler.
>>>>     #
>>>>     # The application 'rake' is installed as part of a gem, and
>>>>     # this file is here to facilitate running it.
>>>>     #
>>>>
>>>>     require 'pathname'
>>>>     ENV['BUNDLE_GEMFILE'] ||= File.expand_path("../../Gemfile",
>>>>       Pathname.new(__FILE__).realpath)
>>>>
>>>>     require 'rubygems'
>>>>     require 'bundler/setup'
>>>>
>>>>     load Gem.bin_path('rake', 'rake')
>>>>
>>>> After doing some research on this I learned it's controversial, a
>>>> surprise for Rails ;)
>>>>
>>>> Now that the dust has settled, what's the generally recommended
>>>> approach?  Keep the Rails-generated binstub for rake, and cronjobs that cd
>>>> into the app directory, or go for a bundler-generated binstub (which
>>>> presumably works from anywhere)?
>>>>
>>>> Thanks in advance,
>>>>
>>>> Andy Stewart
>>>> _______________________________________________
>>>> Chat mailing list
>>>> Chat at lists.lrug.org
>>>> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
>>>> Manage your subscription:
>>>> http://lists.lrug.org/options.cgi/chat-lrug.org
>>>> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>>>
>>>
>>>
>>> --
>>>
>>> ------------------------------
>>> Twitter <http://twitter.com/#!/gerhardlazu> Github
>>> <https://github.com/gerhard> Blog <http://gerhard.lazu.co.uk/>
>>>
>>>
>>
>> --
>>
>> ------------------------------
>> Twitter <http://twitter.com/#!/gerhardlazu> Github
>> <https://github.com/gerhard> Blog <http://gerhard.lazu.co.uk/>
>>
>> _______________________________________________
>> Chat mailing list
>> Chat at lists.lrug.org
>> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
>> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
>> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>
>>
>>
>> _______________________________________________
>> Chat mailing list
>> Chat at lists.lrug.org
>> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
>> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
>> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20141009/8581063f/attachment-0003.html>