bundler 1.0.0 RC makes me crazy

[Ivan Brykov]

Hi everybody!

We recently upgraded to Rails 3 RC which requires new bundler 1.0.0 RC.
After a day wasted trying to make it work we now give up.

Our config is as following:
— Debian
— Ruby Enterprise
— Rails 3 RC
— Apache
— Passenger

We are stuck with following error thrown at us by passenger:
git://github.com/odorcicd/authlogic.git (at rails3) is not checked out.
Please run `bundle install` (Bundler::PathError)

Though until this upgrade everyting worked well.

We already tried to clean up all bundler caches, delete all gems,
reinstall passenger and Ruby Enterprise but nothing helps so far.

Somebody help! ^_^
--
Posted via http://www.ruby-forum.com/.

[Matias Käkelä]

> We are stuck with following error thrown at us by passenger:
> git://github.com/odorcicd/authlogic.git (at rails3) is not checked out.
> Please run `bundle install` (Bundler::PathError)

We have exactly the same problem with slightly different server config.
Somehow Bundler, Passenger or whatever is not finding gems which are
installed directly from git repos. If I vendor git gems like this:

gem "state_machine", :path => 'vendor/git/state_machine'

instead of

gem "state_machine", :git =>
'git://github.com/pluginaweek/state_machine.git'

gems are loaded, but that's not a good solution for a long run since we
have about 10 gems from git repos.

It seems that Bundler or Passenger has difficulties to load git gems
because they are not installed to same gem directory. "bundle show"
gives this output:

bundle show rspec-core (gem from git repo)
/opt/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/bundler/gems/rspec-core-3c32ce5

bundle show thin (gem from rubygems)
/opt/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8/gems/thin-1.2.7

Any help would be appreciated. Should I somehow add 'bundler/gems'
directory to some path variable or what?

[Yehuda Katz]

We have seen a number of reports of this error ("git://git/repo (at
branch) is not checked out. Please run `bundle install`". This is a
serious issue and we're actively investigating it (by actively, I mean
it's what we're going to be working on tomorrow).

Please hang on. We should have another RC in the next day or so that
resolves this issue.

Thanks for your patience!

-- Yehuda Katz

[Matias Käkelä]

Still no luck with Bundler 1.0.0 rc.2. I'm using bundler with
--production switch. Despite that the same issue keeps appearing. Dunno
if I'm doing something wrong or is it a unresolved bug.

[Ivan Brykov]

Matias Käkelä wrote:
> Still no luck with Bundler 1.0.0 rc.2.

Same for me.

[Matias Käkelä]

Ivan Brykov wrote:
> Matias Käkelä wrote:
>> Still no luck with Bundler 1.0.0 rc.2.
>
> Same for me.

Ok, a workaround for the issue is to chmod 777 -R the vendor/gems
directory. That seemed to make it work.

[Ivan Brykov]

Matias Käkelä wrote:
> Ok, a workaround for the issue is to chmod 777 -R the vendor/gems
> directory. That seemed to make it work.

Couldn't find such path under our Rails root. I created 'gems' directory
in [Rails root]/vendor but still no luck.

[Matias Käkelä]

Ivan Brykov wrote:
> Matias Käkelä wrote:
>> Ok, a workaround for the issue is to chmod 777 -R the vendor/gems
>> directory. That seemed to make it work.
>
> Couldn't find such path under our Rails root. I created 'gems' directory
> in [Rails root]/vendor but still no luck.

Vendor gems is a custom directory supplied with --path switch. Default
with --production switch should be vendor/bundle.

[Yehuda Katz]

Does this mean that vendor/gems is owned by a different user than the
one booting the server?

[Matias Käkelä]

Yehuda Katz wrote:
> Does this mean that vendor/gems is owned by a different user than the
> one booting the server?

No, to isolate the issue, we've been running everything as root, nginx,
bundler, etc.

naturally vendor/gems is owned by root, but still bundler/passenger has
issues if vendor/gems is not world writable.

[Yehuda Katz]

It's still possible that the Ruby processes are being run as a
different user. Can you run ps and take a look?

-- Yehuda

[Matias Käkelä]

Yehuda Katz wrote:
> It's still possible that the Ruby processes are being run as a
> different user. Can you run ps and take a look?

Thanks, it wasn't obvious to check the ownership of each and every
process. Alas, this might have been the culprit:

nobody 10560 1.2 2.0 190736 83916 ? S 19:34 0:05 Rack:
/var/www/html/app/current

I'm now using passenger_default_user option in nginx config. Let's hope
that that'll fix the issue.

[Yehuda Katz]

Can you ls -alt vendor/gems?

I'm really curious about this and want to get to the bottom of it.

-- Yehuda

[Matias Käkelä]

Yehuda Katz wrote:
> Can you ls -alt vendor/gems?
>
> I'm really curious about this and want to get to the bottom of it.
>
> -- Yehuda

Yes I can. Should I see something worthwhile with that command?

Btw. unfortunately I'm going on holidays on tomorrow, so I'm not able to
access the server for a while. I can ask my colleague to follow this
thread though.

[Matias Käkelä]

Output currently:

[root@srv current]# ls -alt vendor/gems
lrwxrwxrwx 1 root root 42 Jul 30 16:38 vendor/gems ->
/var/www/html/app/shared/gem

[Ivan Brykov]

Just upgraded to bundler 1.0.0. rc3. Nothing has changed. When can I
expect working solution?

[Jeff Gardner]

I'm in the same boat: bundler 1.0.0.rc3 cant find the gems that are
pulled from git.. Any idea when we might get a solution to this? Or is
this a Passenger bug?

[Luis Correa d'Almeida]

Same here. Although the work around suggested earlier (chmod 777 vendor/gems) works.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To post to this group, send email to rubyonra...@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-ta...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.

[AK]

> We have exactly the same problem with slightly different server config.
> Somehow Bundler, Passenger or whatever is not finding gems which are
> installed directly from git repos. If I vendor git gems like this:

We have the exact same issue, Matias. It only occurred today after we
switched to Ruby Enterprise Edition, which I see you are using as well.

[Michael Hasenstein]

ME TOO!

and here is a backtrace. Using latest rvm (0.1.46), passenger, ruby
1.9.2-p0 (the new official release), latest rails master and bundler
rc5. the trace shows that the correct bundler is used (from rvm
ruby-1.9.2-p0 environment). "bundle check" reports nothing, "rails
server" works just fine. I tried chmod 777-ing the vender directory, no
luck. The only thing that changed during the last few weeks were the
various new bundler RCs, new ruby (from svn), new rvm-versions (as they
happened), and new Rails-updates (daily fresh from github). I think one
of the bundler-rc updates must be the reason - passenger has remained
the same for a while after all, and not too long ago (days?) everything
still worked.

Ruby (Rack) application could not be started
These are the possible causes:

*
There may be a syntax error in the application's code. Please
check for such errors and fix them.
*
A required library may not installed. Please install all libraries
that this application requires.
*
The application may not be properly configured. Please check
whether all configuration files are written correctly, fix any incorrect
configurations, and restart this application.
*
A service that the application relies on (such as the database
server or the Ferret search engine server) may not have been started.
Please start that service.

Further information about the error may have been written to the
application's log file. Please check it in order to analyse the problem.

Error message:
git://github.com/rails/rails.git (at master) is not checked out.
Please run `bundle install` (Bundler::GitError)
Exception class:
PhusionPassenger::UnknownError
Application root:
/home/mha/MYAPP
Backtrace:
# File Line Location
0
/home/mha/.rvm/gems/ruby-1.9.2-p0/gems/bundler-1.0.0.rc.5/lib/bundler/source.rb
558 in `rescue in load_spec_files'
1
/home/mha/.rvm/gems/ruby-1.9.2-p0/gems/bundler-1.0.0.rc.5/lib/bundler/source.rb
556 in `load_spec_files'
2
/home/mha/.rvm/gems/ruby-1.9.2-p0/gems/bundler-1.0.0.rc.5/lib/bundler/source.rb
378 in `local_specs'
3
/home/mha/.rvm/gems/ruby-1.9.2-p0/gems/bundler-1.0.0.rc.5/lib/bundler/source.rb
541 in `specs'
4
/home/mha/.rvm/gems/ruby-1.9.2-p0/gems/bundler-1.0.0.rc.5/lib/bundler/definition.rb
149 in `block in resolve'
5
/home/mha/.rvm/gems/ruby-1.9.2-p0/gems/bundler-1.0.0.rc.5/lib/bundler/definition.rb
147 in `each'
6
/home/mha/.rvm/gems/ruby-1.9.2-p0/gems/bundler-1.0.0.rc.5/lib/bundler/definition.rb
147 in `resolve'
7
/home/mha/.rvm/gems/ruby-1.9.2-p0/gems/bundler-1.0.0.rc.5/lib/bundler/definition.rb
93 in `specs'
8
/home/mha/.rvm/gems/ruby-1.9.2-p0/gems/bundler-1.0.0.rc.5/lib/bundler/definition.rb
137 in `specs_for'
9
/home/mha/.rvm/gems/ruby-1.9.2-p0/gems/bundler-1.0.0.rc.5/lib/bundler/definition.rb
126 in `requested_specs'
10
/home/mha/.rvm/gems/ruby-1.9.2-p0/gems/bundler-1.0.0.rc.5/lib/bundler/environment.rb
23 in `requested_specs'
11
/home/mha/.rvm/gems/ruby-1.9.2-p0/gems/bundler-1.0.0.rc.5/lib/bundler/runtime.rb
11 in `setup'
12
/home/mha/.rvm/gems/ruby-1.9.2-p0/gems/bundler-1.0.0.rc.5/lib/bundler.rb
95 in `setup'
13
/home/mha/.rvm/gems/ruby-1.9.2-p0/gems/passenger-2.2.15/lib/phusion_passenger/utils.rb
222 in `setup_bundler_support'
14
/home/mha/.rvm/gems/ruby-1.9.2-p0/gems/passenger-2.2.15/lib/phusion_passenger/rack/application_spawner.rb
105 in `block in run'
15
/home/mha/.rvm/gems/ruby-1.9.2-p0/gems/passenger-2.2.15/lib/phusion_passenger/utils.rb
323 in `report_app_init_status'
16
/home/mha/.rvm/gems/ruby-1.9.2-p0/gems/passenger-2.2.15/lib/phusion_passenger/rack/application_spawner.rb
87 in `run'
17
/home/mha/.rvm/gems/ruby-1.9.2-p0/gems/passenger-2.2.15/lib/phusion_passenger/rack/application_spawner.rb
65 in `block in spawn_application'
18
/home/mha/.rvm/gems/ruby-1.9.2-p0/gems/passenger-2.2.15/lib/phusion_passenger/utils.rb
252 in `safe_fork'
19
/home/mha/.rvm/gems/ruby-1.9.2-p0/gems/passenger-2.2.15/lib/phusion_passenger/rack/application_spawner.rb
58 in `spawn_application'
20
/home/mha/.rvm/gems/ruby-1.9.2-p0/gems/passenger-2.2.15/lib/phusion_passenger/rack/application_spawner.rb
41 in `spawn_application'
21
/home/mha/.rvm/gems/ruby-1.9.2-p0/gems/passenger-2.2.15/lib/phusion_passenger/spawn_manager.rb
150 in `spawn_application'
22
/home/mha/.rvm/gems/ruby-1.9.2-p0/gems/passenger-2.2.15/lib/phusion_passenger/spawn_manager.rb
278 in `handle_spawn_application'
23
/home/mha/.rvm/gems/ruby-1.9.2-p0/gems/passenger-2.2.15/lib/phusion_passenger/abstract_server.rb
352 in `main_loop'
24
/home/mha/.rvm/gems/ruby-1.9.2-p0/gems/passenger-2.2.15/lib/phusion_passenger/abstract_server.rb
196 in `start_synchronously'
25
/home/mha/.rvm/gems/ruby-1.9.2-p0/gems/passenger-2.2.15/bin/passenger-spawn-server

[Michael Hasenstein]

Oh and I forgot to mention I also tried "bundle pack" - no luck.

Michael Hasenstein wrote:
> ME TOO!
>...

[Michael Hasenstein]

Michael Hasenstein wrote:
> ME TOO!

SOLVED.

I copied my projects to my main machine and in the process cleaned up
the old ruby (1.9.2-head) since I now use the official 1.9.2(-p0)
instead and don't like having useless files lying around. So I ended up
installing all gems fresh. I noticed there was no
.rvm/bin/passenger_ruby - and I read I shouldn't use the ruby binary
directly in the passenger config.

I created passenger_ruby with "rvm 1.9.2 --passenger", updated apache to
load the new passenger module (was in .rvm/..../1.9.2-head/... before,
as I said I now use 1.9.2-p0 and no longer svn head of ruby), MADE SURE
IT LOADS passenger_ruby(!) - passenger-install-apache2-module gives you
the direct link to the ruby binary which apparently is wrong, so don't
copy&paste without looking at what it is!

Both my rails3 apps (different directories, same rvm/ruby/passenger)
work fine now.

[Michael Hasenstein]

No, that wasn't the solution. Simply by ensuring passenger_ruby is
correct (exists, is correct, is used by passenger) did not solve this
problem for me - at least not on my laptop dev. system. The same setup
works on my desktop dev. machine. Same passenger, same rvm, same app,
same ruby - one works, the other one doesn't.

Michael Hasenstein wrote:
> Michael Hasenstein wrote:
>> ME TOO!
>
>
> SOLVED.

[Jacques Fuentes]

This was not the issue for me either. When using bundle install
--deployment, everything works just fine, but this is a development
server and I do not want gems installed to vendor/bundle. The problem is
still with a gem specifying a git repo and a :ref (does not have a
gemspec).

[Claudio Poli]

Jacques Fuentes wrote:
> This was not the issue for me either. When using bundle install
> --deployment, everything works just fine, but this is a development
> server and I do not want gems installed to vendor/bundle. The problem is
> still with a gem specifying a git repo and a :ref (does not have a
> gemspec).

I'm in the same boat, using Rails 2-3-stable (git) and Passenger
3.0.0-beta3.

If the gems aren't in vendor/bundle passenger won't start due to gem
installed and defined through :git

[Ramon Cahenzli]

The problem is still there here as well, running Bundler 1.0.2, Rails
3.0.0 and Rubygems 1.3.7. All gems are installed system-wide as root, no
gems are installed in local user gem directories.

It happens particularly with this gem:

gem 'thinking-sphinx', '2.0.0.rc2', :require => 'thinking_sphinx', :git
=> 'git://github.com/freelancing-god/thinking-sphinx.git', :branch =>
'rails3'

Even if I install this gem by hand as root on the command line, the
problem remains. After running bundle install as root, I get:

Your bundle is complete! Use `bundle show [gemname]` to see where a
bundled gem is installed.

Then, when running any rake task in the Rails project with that Gemfile:

rake aborted!
git://github.com/freelancing-god/thinking-sphinx.git (at rails3) is not

checked out. Please run `bundle install`

But bundle install has run fine and the gem is installed as root.
Running "bundle show thinking-sphinx" as root:

/usr/lib/ruby/gems/1.8/bundler/gems/thinking-sphinx-644f57e2ac68

Running "bundle show thinking-sphinx" as non-root user:

git://github.com/freelancing-god/thinking-sphinx.git (at rails3) is not

checked out. Please run `bundle install`

This is wrong, since there is a system-wide copy of the gem available
that Bundler seems to be unable to see. When running "bundle install" as
normal user, Bundler seems to start to install things to /home/user/ and
then insists on receiving the user's password in order to install it via
sudo, but since the local users are not allowed to use sudo, that
doesn't work either.

We won't give those users any sudoers privileges because they don't need
them. They're just local users set up to run the Rails web apps as.

We're in a dead end then, gem install does install the gem just fine,
but Bundler doesn't see this, while Bundler itself can't install the gem
properly when running as root (?) and can't install a local gem without
asking for sudo (?) unless using the --deployment option.

When running with the --deployment option, gems are installed into the
rails directory in vendor/bundle and this error disappears, but this is
wasteful because it means that each Rails app uses its own copy of the
gems instead of relying on the system-wide copies which may already be
in RAM. This causes a lot of unnecessary overhead that's deadly in
situation with small servers (e.g. virtual servers).

Will it be possible to solve this issue with system-wide gems or is it
something on our side?

Prior to Bundler when working with config.gem instructions in the
config/environment.rb file of a Rails app, thinks worked fine with
system-wide gems.

Thanks!

[Alec L.]

Yes, crazy is the word... Anyway, after some digging, my understanding
is that application code in e. g. rake expects a directory layout as
created by bundle install. In this case, that is bundle install
--deployment.

I have been able to resolve my issues my using the
vendor/bundle dirs created by bundle install --deployment and use them
as the shared gems. In this, there is special arrangements for git gems.
I guess it should be possible to generate the same structure manually,
but since it's not documented I guess it's likely to change.

After all, this is ruby ;)