You could accomplish something pretty similar by creating a Rails template which skips bundle install, downloads a Gemfile.lock you provide, and then run bundle install by itself.
On Wed, Dec 21, 2011 at 01:31, Rodrigo Rosenfeld Rosas <[email protected]>wrote: > ** > Hi Yehuda, thanks for your response. > > I understand what you've said, but what I'm suggesting is that Bundler > could try to resolve all dependencies with local gems first before checking > rubygems.org. > > For instance, if there's currently a coffee-script version that would fit > the requirements in Gemfile for the application being created, Bundler > could use it instead of downloading the latest version. > > Maybe a new option could be included in Bundler like --try-local-first and > made available to the Rails new generator so that we could append it to > ~/.railsrc, for instance. > > Another take would be adding some option to the rails new generator like > "--provided-gemfile-lock" where a Gemfile.lock would be generated while > packaging a Rails release and copied to the created app. > > I'm not sure which would be the better option, but I would really like you > to consider some way of making creating a new Rails application as fast as > it used to be before Rails 3. > > Best, > > Rodrigo. > > Em 20-12-2011 21:12, Yehuda Katz escreveu: > > The reason this happens is that when you run `bundle install` without a > Gemfile.lock (the case in a new Rails app), bundler checks with > rubygems.org to see if there are any new versions available. For > instance, it is possible that you have an old version of coffee-script on > your system. Calling `bundle install` without a `Gemfile.lock` means "make > sure to get the latest versions of my gems that are available." When you > use --local, it means "I assert that the gems are all available locally, > and I want you to use them even if there may be newer ones available." > > Using --local will not work for a new app on a new system, because there > are items in the default `Gemfile` that are not actual dependencies of > Rails. If --local reliably worked, you would not need to run bundle install > at all. This is because if Bundler sees that there is no `Gemfile.lock` > when you require "bundler/setup", it tries to satisfy the dependencies from > your local gems. Unfortunately, it will not always work. > > Yehuda Katz > (ph) 718.877.1325 > > > On Tue, Dec 20, 2011 at 9:35 AM, Rodrigo Rosenfeld Rosas < > [email protected]> wrote: > >> Creating a new Rails app nowadays in my computer with Bundler-pre takes >> about 6s only for running "bundle install" in the end of the new >> generator... >> >> We create a new app instantaneously in Rails 1 and 2. >> >> Shouldn't Bundler try to see if the local dependencies do suffice before >> trying to ping rubygems.org? >> >> For most cases you'll already have all dependencies locally. >> >> Just try: >> >> rails new empty --skip-bundle >> cd empty >> bundle install --local >> >> And you'll see how much faster it is. >> >> But it won't work if you run "rails new empty -d postgres" and don't have >> postgres already installed. >> >> So, shouldn't Bundler try to resolve locally first by default and then >> use the normal method with the requests to rubygems.org? >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby on Rails: Core" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/rubyonrails-core?hl=en. >> >> > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. > > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
