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 <http://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] <mailto:[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 <http://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
<http://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]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto:rubyonrails-core%[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.
