Rails core - Dec 2011 - Why isn't bundle run with "--local" on rails new generator?

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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

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.orgto 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
<rr.rosas@gmail.com
> 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
rubyonrails-core@googlegroups.**com<rubyonrails-core@googlegroups.com>
> .
> To unsubscribe from this group, send email to
>
rubyonrails-core+unsubscribe@**googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at http://groups.google.com/**
>
group/rubyonrails-core?hl=en<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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

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 
> <rr.rosas@gmail.com <mailto:rr.rosas@gmail.com>> 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
>     rubyonrails-core@googlegroups.com
>     <mailto:rubyonrails-core@googlegroups.com>.
>     To unsubscribe from this group, send email to
>     rubyonrails-core+unsubscribe@googlegroups.com
>     <mailto:rubyonrails-core%2Bunsubscribe@googlegroups.com>.
>     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 rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to 
> rubyonrails-core+unsubscribe@googlegroups.com.
> 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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

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
<rr.rosas@gmail.com>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 <
> rr.rosas@gmail.com> 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 rubyonrails-core@googlegroups.com.
>> To unsubscribe from this group, send email to
>> rubyonrails-core+unsubscribe@googlegroups.com.
>> 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 rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to
> rubyonrails-core+unsubscribe@googlegroups.com.
> 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 rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to
> rubyonrails-core+unsubscribe@googlegroups.com.
> 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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

I can''t find the official documentation for Rails application
templates,
but I guess they won''t allow you to pass any arguments to the new
generator.

Maybe I would have to specify "--skip-bundle -m
path/to/my/template.rb"
in my ~/.railsrc and use the template for running "bundle install 
--local"...

Em 21-12-2011 01:51, Pedro Nascimento escreveu:
> 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 
> <rr.rosas@gmail.com <mailto:rr.rosas@gmail.com>> 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 <http://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 <tel:20-12-2011%2021>: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 <tel:718.877.1325>
>>
>>
>>     On Tue, Dec 20, 2011 at 9:35 AM, Rodrigo Rosenfeld Rosas
>>     <rr.rosas@gmail.com <mailto:rr.rosas@gmail.com>> 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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.