bundle install defaults to installing all groups

[Vanuan]

Currently bundle install defaults to installing all groups. This is not very nice to require a user to install development dependencies. I think that test and development groups should be opt-in, not opt-out. Because developers are always a minority.

Here's a discussion on that:
backlogs/redmine_backlogs@200e111#commitcomment-1097937

Maybe there's a way to opt-in not opt-out groups?

[rohitarondekar]

I believe the #1688 issue is related to this. I'm guessing this is on the minds of the maintainers of Bundler, at the very least. :)

[Vanuan]

I'm glad to hear it!

Is there any timeframe we could see this implemented? Would it be months or years? I mean, will it be a major (2.0) or a minor (1.2) change in the version?

[rohitarondekar]

Judging by the title of that issue, being 'investigate', I don't think there is any definite time frame. Although I'm sure other ideas to solve this problem would be welcome. :)

[Vanuan]

I don't think that changing the default behaviour (interface change) would require deep investigation.

I just want that bundle install would do the same as bundle install --without the_list_of_all_groups_except_default does.

I.e. If I have the following in my Gemfile:

gem ...

group :production do
gem ...
end

group :development do
gem ...
end

group :test do
gem ...
end

group :etc do
gem ...
end

And I run bundle install

Then bundler installs only gems listed in the production group

So that users won't be forced to run bundler --without test development etc

And

If I run bundle install --all
Then bundler will install all gems, I.e. the same as bundle install does currently
So that developer will still be able to install development gems

[rohitarondekar]

Yup, I understood that. The issue I pointed out is for using information in the Gemfile.lock to decide which groups to include/exclude. Which in hindsight wouldn't help directly and would still need a workaround.

Might I suggest not making your end users using bundle install directly and instead have them use a rake task like rake install ― which would provide the correct --without options to Bundler.

If Bundler were to install some default group and exclude others, how should this group name be communicated to Bundler? I think that is an important decision to be made, right? My initial thought is a project-wide config file, maybe a .bundler or something. And these settings can be overridden by the .bundle/config.

What do you think?

/cc @indirect

[radar]

The --without option is a remembered option. This means if you commit your .bundle/config to your repository, other people running bundle install will have Bundler operate with the same --without switch as you used originally.

-1 for it defaulting to NOT installing development + test groups. This is primarily what I use it for.

[Vanuan]

Might I suggest not making your end users using bundle install directly and instead have them use a rake task like rake install ― which would provide the correct --without options to Bundler.

So the bundler is intended to be used only by developers?

how should this group name be communicated to Bundler

Well, we can default to NOT installing all groups and require user to have something like this in her Gemfile:

default_groups
  production
end

This means if you commit your .bundle/config to your repository, other people running bundle install will have Bundler operate with the same --without switch as you used originally.

Can I override this behavior using some --with flag, so I wouldn't have to remove .bundle/config in my test environment?

The approaches you suggested look like workarounds to me.

-1 for it defaulting to NOT installing development + test groups. This is primarily what I use it for.

So bundler is not used by your users? Or you wouldn't mind if some application forced you to install a gem you don't need?

[Vanuan]

how should this group name be communicated to Bundler

I see that the default group already exists:

The :default group includes all gems not listed under any group.

I just has to be available to bundle install.

[indirect]

@Vanuan, you seem to have a very different idea of "users" than we do. Bundler is a tool for developers, to help them develop and deploy applications written in ruby. Anyone who is checking out a git repository is (sort of, at least) a developer, so Bundler is optimized to support the developer workflow.

There is no simple --with production option because that is a rare use-case. CI servers, production servers, and development machines may all need different groups installed, and we have found it less confusing to have a single clear option that excludes any groups that should not be installed.

Any ruby-based application that is deployed to a server will (hopefully, hah) use some sort of deployment script. For example, Bundler ships with bundler/capistrano and bundler/vlad, and others have written their own scripts. Those scripts all include the option --without development test, and can be trivially overwritten to add any other groups that you may want to exclude.

If an application is being distributed for use instead of development, I strongly suggest that you use the --path vendor/bundle option, to ensure that the gems being installed will not conflict or interfere with the overall system's installed gems.

Furthermore, if you are planning on shipping your application to true end-users, I strongly suggest that you do not ask them to run bundle install at all. Instead, package your application so they can simply download it and then run it. You may want to investigate the new bundle install --standalone option that is part of Bundler 1.1, which was designed to assist with that exact problem.

In conclusion, we would prefer not to add a --with option. While it would be relatively straightforward to write the code to implement, we want to keep Bundler optimized for the majority of those who use it. We also want to keep it the code as simple as we can, as well as making it easier for anyone using Bundler to figure out what gems will be installed.

Thanks for the feedback. As always, we appreciate it.

[Vanuan]

Furthermore, if you are planning on shipping your application to true end-users, I strongly suggest that you do not ask them to run bundle install at all. Instead, package your application so they can simply download it and then run it. You may want to investigate the new bundle install --standalone option that is part of Bundler 1.1, which was designed to assist with that exact problem.

It would be great if I could do so. The problem comes when a user wants to install a plugin (Rails 3 Engine) to an application. Rails 3 Engine is a gem that can require an arbitary set of gems with different versions. So bundler helps in this situation. Now I see that it is not a purpose of bundler to solve a problem of installing gems. It is sad.

[radar]

Now I see that it is not a purpose of bundler to solve a problem of installing gems. It is sad.

Wat.

Bundler's purpose is to solve a problem of installing gems.

Could you go into more detail about how it doesn't solve this particular problem?

[Vanuan]

There is no simple --with production option because that is a rare use-case.
we want to keep Bundler optimized for the majority of those who use it.

I.e. it is a developer tool, not a tool that helps deliver gems to the user.

[radar]

Correct. It is not difficult to build a rake task as Rohit suggests and get users to install gems that way.

Ryan Bigg

On Monday, 19 March 2012 at 2:39, John Yani wrote:

There is no simple --with production option because that is a rare use-case.
we want to keep Bundler optimized for the majority of those who use it.

I.e. it is a developer tool, not a tool that helps deliver gems to the user.

---

Reply to this email directly or view it on GitHub:
#1771 (comment)