Does not appear to work with Rails 3.2.3 #26

Closed
sampablokuper opened this Issue May 31, 2012 · 17 comments

Projects

None yet

5 participants

@sampablokuper

The Installation section of the readme says:

    gem install rubygems-bundler

Next run (once):

    gem regenerate_binstubs

And you're done!

However, I find that rails server still needs to be invoked with the incantation bundle exec rails server:

$ rails server
Rails is not currently installed on this system. To get the latest version, simply type:

    $ sudo gem install rails

You can then rerun your "rails" command.
$ bundle exec rails server
=> Booting WEBrick
=> Rails 3.2.3 application starting in development on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
[2012-05-31 05:13:51] INFO  WEBrick 1.3.1
[2012-05-31 05:13:51] INFO  ruby 1.9.3 (2012-04-20) [x86_64-darwin10.8.0]
[2012-05-31 05:13:51] INFO  WEBrick::HTTPServer#start: pid=1220 port=3000
^C[2012-05-31 05:15:30] INFO  going to shutdown ...
[2012-05-31 05:15:30] INFO  WEBrick::HTTPServer#start done.
Exiting
$ gem regenerate_binstubs
bundler 1.1.3
rake 0.9.2.2
rubygems-bundler 1.0.2
$ rails server
Rails is not currently installed on this system. To get the latest version, simply type:

    $ sudo gem install rails

You can then rerun your "rails" command.
$ bundle exec rails server
=> Booting WEBrick
=> Rails 3.2.3 application starting in development on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
[2012-05-31 05:13:51] INFO  WEBrick 1.3.1
[2012-05-31 05:13:51] INFO  ruby 1.9.3 (2012-04-20) [x86_64-darwin10.8.0]
[2012-05-31 05:13:51] INFO  WEBrick::HTTPServer#start: pid=1220 port=3000
^C[2012-05-31 05:15:30] INFO  going to shutdown ...
[2012-05-31 05:15:30] INFO  WEBrick::HTTPServer#start done.
Exiting
@mpapis mpapis was assigned May 31, 2012
@mpapis
Ruby enVironment Manager member

did you use any additional parameters for bundle install can I see .bundle/config from the project dir?

@sampablokuper

Yes, here's the .bundle/config:

---
BUNDLE_PATH: vendor
BUNDLE_DISABLE_SHARED_GEMS: '1'
BUNDLE_WITHOUT: production
@mpapis
Ruby enVironment Manager member

rubygems-bundler integrates on the level of shared gems, your setup explicitly disables shared gems BUNDLE_DISABLE_SHARED_GEMS: '1' you should not use --standalone or other options that install gems into local directory, bundler takes care of separating your gems from shared gems while loading, no need to separate it to local directory.

the easiest fix would be to:

rm -rf vendor .bundle
bundle install --without=production

I'm not sure if you have anything more except bundled gems in vendor you might be better with removing only vendor/ruby

@sampablokuper

Shouldn't rubygems-bundler be path agnostic, i.e. effective at removing the need to use bundle exec ... regardless of whether the --path option was passed to bundler?

Incidentally, I was following the advice here: http://ryan.mcgeary.org/2011/02/09/vendor-everything-still-applies

@mpapis
Ruby enVironment Manager member

Bundler was developed to resolve the dependency problems, it allows keeping all your gems in one location and loading only required gems, this removes the need of vendoring your gems within your application - if this is not the case then I would call it a bug and it should be reported ASAP to the bundler team.

Going back to rubygems-bundler - it's solution which avoids changing your environment to allow you using gems in versions specified in Gemfile - effectively removing the need to use bundle exec. To accomplish this it hooks up to existing infrastructure provided by rubygems, it backports custom shebang from rubygems 2.0 to any earlier rubygems version using rubygems plugin.

So as rubygems-bundler uses rubygems to achieve the integration it will only work with rubygems compatible behaviors and bundle install --path ... or bundle install --standalone are not rubygems compatible. (you could hook into it with a shell tool, but gem is not a good place for it)

@sampablokuper

Thanks for the info about the way rubygems-bundler is implemented and the limitations this produces. I guess whether the issue I've reported counts as a rubygems-bundler bug depends on whether the aim of rubygems-bundler is to allow bundler users generally the ability to avoid using bundle exec, or only bundler users who haven't invoked bundler's --path option.

If the latter, then my issue is surely invalid:wontfix; if the former, then maybe the implementation you've picked for rubygems-bundler should be reconsidered for a future milestone.

Thanks again for your help.

@mpapis
Ruby enVironment Manager member

To allow integration which would make --path installations working it would be required to merge into bundler and internal bundler changes or building shell integration.

Manual Fix

It's possible to make it work without changes, just install the gems to global namespace also, it will allow rubygems-bundler to hook to the binaries and load Bundler when required:

bundler install --system
bundler install --path=vendor

When there is no Gemfile or gem is not in Gemfile - gem will be loaded from system, when gem is in Gemfile - it will be loaded using bundle exec.

Bundler integration

bundler skips standard rubygems plugins when installing using --path, it would require internal changes and also generate the "aware" wrappers in system gems location, this most likely would fix #21 too ... I think it's the way to go, but it requires to start working on bundler 1.3 from my side - I promise to get back to it later - as it's the aim anyway.

Shell integration

As the aim of this gem was to get rid of multiple implementations (rvm, oh-my-zsh, aliases, rbenv) that all were fixing this problem by modifying environment - I will not consider going into this direction.

@sampablokuper

Good stuff; thanks again.

@patcon

Thanks guys. I was hitting this too, and while it's a minor minor inconvenience, I'm in a situation where I don't need to use --path -- my mind just liked everything project-related being in one place :)

Thanks for the awesome tool!

@patcon patcon added a commit to myplanetdigital/jenkins-inception that referenced this issue Jun 29, 2012
@patcon patcon Not longer need `bundle exec`. Had to remove --path arg for bundler u…
…ntil resolved: rvm/rubygems-bundler#26.
23d4a7f
@richardkmichael

I have gems for a Rails app Gemfile installed by the capistrano bundle integration into shared/bundle. I have passenger installed into an RVM gemset.

passenger will not run, because the noexec wrapper is unable to find it; gist.

From reading this issue, I thought it was BUNDLE_DISABLE_SHARED_GEMS: '1'. However, the problem remains even if I set this to 0.

Is it related to this perhaps?

@mpapis
Ruby enVironment Manager member

it is not only BUNDLE_DISABLE_SHARED_GEMS: '1' - it is also BUNDLE_PATH: vendor, because of those bundler does not run rubygems plugins - which prevents rubygems-bundler from doing it's job.

There are two solutions I can think of to generate the binaries in (rubygems) PATH:

  1. Move rubygems-bundler into bundler so it can be hooked there,
  2. Add support for plugins in bundler so rubygems-bundler can be a plugin for it too.

I was planning to work on 1. ... but lately I came to think 2. is better option and easier to get accepted in bundler - if at all.

@richardkmichael

Thanks!

If I understand correctly, there is an unavoidable conflict in this scenario:

  • passenger cannot be in the application Gemfile; and therefore, not managed by bundler. It must be installed into the system gem location, e.g. an RVM gemset, either @global or app-specific.

  • By default, bundler/capistrano uses bundler's --deployment option to install gems into shared/bundle. As you explained, bundler will not run plugins in this situation and therefore rubygems-bundler cannot expose the system gems to bundler, thus passenger is not detected.

When using RVM, the solutions I see are:

  • change bundler/capistrano to not use --deployment, and instead install all gems into the system location, e.g. an RVM gemset. (I've done this in the past, but I'm trying to have all defaults work together, if possible.)

  • change to a different app-server which can be in the Gemfile; ex. Puma. (I will explore this today.)

I can't comment on your approaches, 1 or 2 above. I only have this problem with a very specific case (passenger), so I'm uncertain how other people are affected by their use-cases or requirements.

@mpapis
Ruby enVironment Manager member

why in the first place you can not include passenger in Gemfile? have you tried to put it in production group and installing on development machines using --without production, this option is remembered and you need to use it only once.

@richardkmichael

On the passenger mailing list @FooBarWidget advised me to leave it out of the Gemfile entirely. Indeed, that is the way I have previously installed passenger -- as a system gem. This time, I tried to use bundler (mostly for convenience; same app-server in development and production, and installed by capistrano).

Are you able to read this without being a Google Group member?

If not, quoting:

> I am trying to run passenger standalone using an RVM wrapper calling "bundle 
> exec passenger start", from it's bundler installed location (capistrano: 
> "shared/bundle/..."), and preferred to keep all related configuration 
> together. 

You're not supposed to use Phusion Passenger through Bundler. You're 
not supposed to list 'passenger' in your Gemfile. Phusion Passenger 
doesn't work like the other app servers - you should completely leave 
it from your Gemfile. 'passenger start' should just work, no 'bundle 
exec' or whatever. 
@mpapis
Ruby enVironment Manager member

passenger has 4 runtime dependencies, if it ever happens you will need to run/install special versions of those dependencies (company policy, avoiding bugs), then you will need bundler to manage dependencies, banning passenger+bundler usage by @FooBarWidget is not fair ... although some explanation should be given, it looks like you could compare this situation to two gemsets, where application is installed in one and passenger in second.

@FooBarWidget

You misunderstand, I am not banning Bundler. There is a technical reason why it is unnecessary to add passenger to the Gemfile. You can do it but it will literally not bring you any benefits.

The technical reason why other app servers such as Thin must be added to Gemfile is because they first load Rack, then load the application itself its own process, which may depend on a specific version of Rack. If Thin had already loaded a different version of Rack, then things blow up. Because of this you have to use 'bundle exec', but then Thin would only work if you include it in Gemfile.

Phusion Passenger doesn't work this way. It spawns a process, which first explicitly activates Bundler (loading the Gemfile), then loads Rack, then loads the app. You could say that Phusion Passenger already performs an implicit 'bundle exec' for you.

@pho3nixf1re pho3nixf1re referenced this issue in matschaffer/knife-solo Nov 30, 2012
Closed

error on "kitchen" command #112

@mpapis
Ruby enVironment Manager member

--standalone or --deployment lead to disabling shared gems and this is when rubygems-bundler can not be loaded, in that case explicit call to bundle exec is required, optionally it could be simpler with:

bundle install --standalone --binstubs=$GEM_HOME/bundle/bin
PATH="$GEM_HOME/bundle/bin:$PATH"

this might be added in rvm as an option, but will not be added to rubygems-bundler as I agree with @indirect on this one - user picked to isolate application gems from rubygems and no rubygems code should be involved, those either the PATH solution should be used or call via bundle exec

@mpapis mpapis closed this Nov 30, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment