Skip to content

Instantly share code, notes, and snippets.

@wycats
Created May 27, 2012 02:30
Show Gist options
  • Star 4 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save wycats/85d4c0a9844b11f104cb to your computer and use it in GitHub Desktop.
Save wycats/85d4c0a9844b11f104cb to your computer and use it in GitHub Desktop.

User does COMMAND (rake, rackup, gist, rails, etc.). What does he mean?

There is no Gemfile in the directory

The user almost certainly means to run the binary against system. Success!

There is a Gemfile in the directory

Ambiguous. It depends on a few more details.

There is no Gemfile.lock or the Gemfile.lock is out of date

Ambiguous. The user may be using a system command to bootstrap (e.g. rake bundle).

If we choose bundle exec, the command will fail because the gems are not available on the system.

If we choose the system, they may be running a command like rackup, which should fail if the necessary gems are not available on the system.

The Gemfile.lock is up to date

Ambiguous.

Are all of the gems in the Gemfile.lock present on the system? If not, ambiguous. The user may be using a system command to bootstrap.

Is the gem associated with the executable present in the Gemfile.lock, and specified as a top-level gem? If so, the user almost certainly wants bundle exec. Success!

Is the gem associated with the executable present in the Gemfile.lock, but not specified as a top-level gem? If so, ambiguous. We cannot tell whether the user knows that the gem is a dependency of a gem they included. Example: rdoc is a dependency of a number of gems. If the user types rdoc, do they know that?

Is the gem unassociated with any gem in the Gemfile.lock. If so, the user almost certainly does not want bundle exec. Success!

@wagenet
Copy link

wagenet commented May 27, 2012

I agree with this analysis.

@alloy
Copy link

alloy commented May 27, 2012

Indeed.

@mcmire
Copy link

mcmire commented May 27, 2012

HMMMM

@comboy
Copy link

comboy commented May 27, 2012

There's a lot of magic involved in bundler. All well thought and did for user convenience. But I would still prefer simplicity. For example oh-my-zsh bundler plugin will execute everything through bundle exec when Gemfile is present and all that analysis is very important. But I don't like that approach, because IMHO it will never work nicely, because of shell extensions, aliases, need for whitelist and stuff. I would like bundler to always execute stuff from Gemfile. If user wants to bootstrap, he should not use "bundle exec". Just random 2 cents, thanks for sharing these thoughts.

@wycats
Copy link
Author

wycats commented May 27, 2012

@comboy this analysis is about people who are requesting that we make simple commands (without bundle exec) guess whether bundle exec is required. This would make "If user wants to bootstrap, he should not use "bundle exec" impossible.

@comboy
Copy link

comboy commented May 27, 2012

@wycats, oh, sorry I misunderstood (I think then, that these people should leave magic of guessing that to their shells, keeping bundler as clean and simple as possible, especially that it would seem that decision may depend on user preference), thanks for explaining

@Aupajo
Copy link

Aupajo commented May 27, 2012

When require "bundler/setup" is used, that signifies an unambiguous intent to use Bundler. A Rakefile can potentially choose whether or not to require Bundler at the task level, working for both regular tasks that need Bundler and bootstrap tasks.

@comboy
Copy link

comboy commented May 27, 2012

btw, some quirk I had to fight some time ago: https://gist.github.com/973177

Currently I'm using Bundler.with_clean_env, but I still have to provide BUNDLE_GEMFILE='"Gemfile" to make it working (when executing bunler commands from within another project that is also using bundler). I was wondering why with clean env this BUNDLE_GEMFILE still is necessary (sorry that it's not completely relevant to above ;)

@wycats
Copy link
Author

wycats commented May 27, 2012

We should have a fix for that issue in 1.2 :)

@comboy
Copy link

comboy commented May 27, 2012

@wycats, sweet, thanks :)

@joliss
Copy link

joliss commented Jun 2, 2012

So I take it that unlike what this post says, rubygems-bundler likely won't be part of bundler, because there are too many ambiguous cases?

@mcmire
Copy link

mcmire commented Jun 4, 2012

That's kinda what I'm wondering too. I'm also wondering if incorporating Bundler-like abilities into RubyGems (which is planned / being considered for 2.0, IIUC) are not such a good idea after all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment