New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please support conditional gems #1636

Closed
FooBarWidget opened this Issue Jan 19, 2012 · 52 comments

Comments

Projects
None yet
@FooBarWidget

FooBarWidget commented Jan 19, 2012

(Also mentioned on the Phusion blog)
Some people are writing apps that are not only meant to be used internally, but also by the general public. Think RedMine. These apps typically allow the user to choose their database driver through config/database.yml. However the driver must also be specified inside Gemfile, otherwise the app cannot load it. The result is that the user has to edit both database.yml and Gemfile, which introduces the following problems:

  • The user may not necessarily be a Ruby programmer. The Gemfile will confuse him.
  • The user is not able to use the Gemfile.lock that the developer has provided. This makes installing in deployment mode with the developer-provided Gemfile.lock impossible.

This can be worked around in a very messy form with groups. For example:

group :driver_sqlite do
  gem 'sqlite3'
end

group :driver_mysql do
  gem 'msyql'
end

group :driver_postgresql do
  gem 'pg'
end

And then, if the user chose to use MySQL:

bundle install --without='driver_postgresql driver_sqlite'

This is messy because you have to exclude all the things you don't want. If the app supports 10 database drivers then the user has to put 9 drivers on the exclusion list.

I propose supporting conditionals in the Gemfile language. Example:

condition :driver => 'sqlite' do
  gem 'sqlite3'
end

condition :driver => 'mysql' do
  gem 'mysql'
end

condition :driver => 'postgresql' do
  gem 'pg'
end

condition :driver => ['mysql', 'sqlite'] do
  gem 'foobar'
end

The following command would install the mysql and the foobar gems:

bundle install --condition driver=mysql

Here, Bundler must enforce that the driver condition is set; if it's not set then it will raise an error. To allow for the driver condition to not be set, the developer must explicitly define that the condition may be nil:

condition :driver => nil do
  gem 'null-database-driver'
end

Here, bundle install will install null-database-driver.

@joelmoss

This comment has been minimized.

Show comment
Hide comment
@joelmoss

joelmoss Jan 19, 2012

Contributor

I kinda like this, and I don't think it would be that hard to implement.

Contributor

joelmoss commented Jan 19, 2012

I kinda like this, and I don't think it would be that hard to implement.

@pjg

This comment has been minimized.

Show comment
Hide comment
@pjg

pjg Jan 19, 2012

Looks reasonable.

pjg commented Jan 19, 2012

Looks reasonable.

@nicolasblanco

This comment has been minimized.

Show comment
Hide comment
@nicolasblanco

nicolasblanco Jan 19, 2012

Contributor

+1

Contributor

nicolasblanco commented Jan 19, 2012

+1

@croby

This comment has been minimized.

Show comment
Hide comment
@croby

croby Jan 19, 2012

+1

Alternatively, maybe the semantics could just change to --with instead of --without, so anything in a group must be explicitly included instead of excluded

croby commented Jan 19, 2012

+1

Alternatively, maybe the semantics could just change to --with instead of --without, so anything in a group must be explicitly included instead of excluded

@wmoxam

This comment has been minimized.

Show comment
Hide comment
@wmoxam

wmoxam Jan 19, 2012

Not a fan. This is only marginally easier for app users, really they should not have to manually run Bundler at all.

What would be best for users would be to include an installation script with the app that asked for db connection information, and then handled everything else. Perhaps a tool that could generate such a script is in order?

wmoxam commented Jan 19, 2012

Not a fan. This is only marginally easier for app users, really they should not have to manually run Bundler at all.

What would be best for users would be to include an installation script with the app that asked for db connection information, and then handled everything else. Perhaps a tool that could generate such a script is in order?

@FooBarWidget

This comment has been minimized.

Show comment
Hide comment
@FooBarWidget

FooBarWidget Jan 19, 2012

@wmoxam You mean like this? We've been trying that for a while now and I think it's a dead end. Waph tries very hard to integrate with Bundler (not replacing Bundler) and the result is always more complicated than I like and doesn't really work well with edge cases that occur often.

FooBarWidget commented Jan 19, 2012

@wmoxam You mean like this? We've been trying that for a while now and I think it's a dead end. Waph tries very hard to integrate with Bundler (not replacing Bundler) and the result is always more complicated than I like and doesn't really work well with edge cases that occur often.

@jrochkind

This comment has been minimized.

Show comment
Hide comment
@jrochkind

jrochkind Jan 19, 2012

Contributor

-1

I don't understand why you are distributing a Gemfile.lock to multiple sites/users. That's not what Gemfile.lock is for.

If you have shared code, it should be distributed as a gem instead. With Rails 3.x, it is quite possible to ship an entire app as an engine gem that would then be included in a rails app that may itself be nothing more than a basic skeleton (with local database.yml, as well as local Gemfile/Gemfile.lock) rails app as created with 'rails g app' and adding the engine gem to Gemfile.

A Gemfile.lock is not meant for distributing shared code dependencies -- that's what a gemspec is for. You can lock to specific versions in a gemspec if you want to, to get the same effect you are getting now by distributing a 'shared' Gemfile. But a 'shared' Gemfile is going to cause you problems in ways other than this one, adding this feature to make it look like a Gemfile can be used in this way is only going to cause people problems down the line, because Gemfile/Gemfile.lock were never meant to be used in this way, and are going to fail in other ways too. Gemfile.lock especially was clearly designed to track a particular installations current dependency usage, not to be shared with shared code. Rather, a gemspec in a gem itself, and it's dependencies, is what's intended to express the dependency needs of shared code (and gives you the option of locking to single specific versions and not ranges still, if you want to use it).

Contributor

jrochkind commented Jan 19, 2012

-1

I don't understand why you are distributing a Gemfile.lock to multiple sites/users. That's not what Gemfile.lock is for.

If you have shared code, it should be distributed as a gem instead. With Rails 3.x, it is quite possible to ship an entire app as an engine gem that would then be included in a rails app that may itself be nothing more than a basic skeleton (with local database.yml, as well as local Gemfile/Gemfile.lock) rails app as created with 'rails g app' and adding the engine gem to Gemfile.

A Gemfile.lock is not meant for distributing shared code dependencies -- that's what a gemspec is for. You can lock to specific versions in a gemspec if you want to, to get the same effect you are getting now by distributing a 'shared' Gemfile. But a 'shared' Gemfile is going to cause you problems in ways other than this one, adding this feature to make it look like a Gemfile can be used in this way is only going to cause people problems down the line, because Gemfile/Gemfile.lock were never meant to be used in this way, and are going to fail in other ways too. Gemfile.lock especially was clearly designed to track a particular installations current dependency usage, not to be shared with shared code. Rather, a gemspec in a gem itself, and it's dependencies, is what's intended to express the dependency needs of shared code (and gives you the option of locking to single specific versions and not ranges still, if you want to use it).

@mjonuschat

This comment has been minimized.

Show comment
Hide comment
@mjonuschat

mjonuschat commented Jan 20, 2012

+1

@mickey

This comment has been minimized.

Show comment
Hide comment
@mickey

mickey Jan 20, 2012

For our project we used the rvmrc to ask in the shell which version of a gem you want to use (local vs remote) and we set an env variable with something like :

echo "Would you like to use local version of shared_config ? (shell-wide setting)"
select yn in "Yes" "No"; do
case $yn in
  Yes) export LIC_LOCAL_CONFIG=1;;
  No) unset -v LIC_LOCAL_CONFIG;;
esac
  break
done

In our Gemfile we have conditions like this :

if ENV["LIC_LOCAL_CLIENT"]
  gem 'shared_config', :path => '../shared_config'
else
  gem 'shared_config', :git => "git@github.com:citizencast/shared_config.git"
end

It's not ideal but it works quite well.

mickey commented Jan 20, 2012

For our project we used the rvmrc to ask in the shell which version of a gem you want to use (local vs remote) and we set an env variable with something like :

echo "Would you like to use local version of shared_config ? (shell-wide setting)"
select yn in "Yes" "No"; do
case $yn in
  Yes) export LIC_LOCAL_CONFIG=1;;
  No) unset -v LIC_LOCAL_CONFIG;;
esac
  break
done

In our Gemfile we have conditions like this :

if ENV["LIC_LOCAL_CLIENT"]
  gem 'shared_config', :path => '../shared_config'
else
  gem 'shared_config', :git => "git@github.com:citizencast/shared_config.git"
end

It's not ideal but it works quite well.

@halves

This comment has been minimized.

Show comment
Hide comment
@halves

halves Jan 20, 2012

+1
I think that conditions is a generic path that can be used and abused to solve even more problems than this one.

halves commented Jan 20, 2012

+1
I think that conditions is a generic path that can be used and abused to solve even more problems than this one.

@FooBarWidget

This comment has been minimized.

Show comment
Hide comment
@FooBarWidget

FooBarWidget Jan 20, 2012

@mickey if statements won't do. The point is to let Bundler know your entire dependency graph so that Gemfile.lock does not have to be changed upon switching the database driver. As soon as you introduce Ruby-level if statements you lose that ability.

FooBarWidget commented Jan 20, 2012

@mickey if statements won't do. The point is to let Bundler know your entire dependency graph so that Gemfile.lock does not have to be changed upon switching the database driver. As soon as you introduce Ruby-level if statements you lose that ability.

@mislav

This comment has been minimized.

Show comment
Hide comment
@mislav

mislav Jan 20, 2012

Contributor

+1. I've been wanting something that's the opposite of without for a long time now.

However, must it look like a new concept? All we want is a group that is excluded by default, and you have to include it explicitly with something like:

bundle install --with=postgresql

In the Gemfile, it can look like groups too:

group :postgres, :optional => true do
  gem 'pg'
end

This has several advantages:

  1. No new concepts in Gemfile
  2. No new DSL extensions
  3. (Probably) easier to implement
  4. Easier to understand & remember
Contributor

mislav commented Jan 20, 2012

+1. I've been wanting something that's the opposite of without for a long time now.

However, must it look like a new concept? All we want is a group that is excluded by default, and you have to include it explicitly with something like:

bundle install --with=postgresql

In the Gemfile, it can look like groups too:

group :postgres, :optional => true do
  gem 'pg'
end

This has several advantages:

  1. No new concepts in Gemfile
  2. No new DSL extensions
  3. (Probably) easier to implement
  4. Easier to understand & remember
@croby

This comment has been minimized.

Show comment
Hide comment
@croby

croby Jan 20, 2012

@mislav I dig that approach

croby commented Jan 20, 2012

@mislav I dig that approach

@FooBarWidget

This comment has been minimized.

Show comment
Hide comment
@FooBarWidget

FooBarWidget Jan 20, 2012

I like mislav's suggestion. That makes things look simpler.

FooBarWidget commented Jan 20, 2012

I like mislav's suggestion. That makes things look simpler.

@schmurfy

This comment has been minimized.

Show comment
Hide comment
@schmurfy

schmurfy Jan 21, 2012

I also like mislav approach, even if I did not ran into a case where I would use it. Bundler does it's job really and should stay as simple as possible.

schmurfy commented Jan 21, 2012

I also like mislav approach, even if I did not ran into a case where I would use it. Bundler does it's job really and should stay as simple as possible.

@radar

This comment has been minimized.

Show comment
Hide comment
@radar

radar Jan 22, 2012

Contributor

Yup, mislav's approach definitely seems sensible.

Contributor

radar commented Jan 22, 2012

Yup, mislav's approach definitely seems sensible.

@adurity

This comment has been minimized.

Show comment
Hide comment
@adurity

adurity Jan 25, 2012

+1 for @mislav solution.

adurity commented Jan 25, 2012

+1 for @mislav solution.

@ryansch

This comment has been minimized.

Show comment
Hide comment
@ryansch

ryansch Feb 10, 2012

+1 for mislav's solution as well

ryansch commented Feb 10, 2012

+1 for mislav's solution as well

@myabc

This comment has been minimized.

Show comment
Hide comment
@myabc

myabc Feb 12, 2012

Contributor

+1 for @mislav's solution

Contributor

myabc commented Feb 12, 2012

+1 for @mislav's solution

@rubiii

This comment has been minimized.

Show comment
Hide comment
@rubiii

rubiii Feb 14, 2012

Contributor

could someone from the core team please comment on whether they would accept a patch to support this?

Contributor

rubiii commented Feb 14, 2012

could someone from the core team please comment on whether they would accept a patch to support this?

@mitfik

This comment has been minimized.

Show comment
Hide comment
@mitfik

mitfik Feb 20, 2012

+1 for @mislav's solution

Edit: it look like it is already implemented :)

$ bundle install --without test development

p.s. maybe someone could close this issue?

mitfik commented Feb 20, 2012

+1 for @mislav's solution

Edit: it look like it is already implemented :)

$ bundle install --without test development

p.s. maybe someone could close this issue?

@dup2

This comment has been minimized.

Show comment
Hide comment
@dup2

dup2 Mar 20, 2012

+1 for @mislav's suggestion

dup2 commented Mar 20, 2012

+1 for @mislav's suggestion

@parndt

This comment has been minimized.

Show comment
Hide comment
@parndt

parndt Mar 21, 2012

Contributor

@mitfik yes, --without is implemented but the option case applies to --with which is not implemented. Optional groups would not be bundled by default. See @mislav's comment.

Provided this would not add any complexity, I'd 👍 this.

Contributor

parndt commented Mar 21, 2012

@mitfik yes, --without is implemented but the option case applies to --with which is not implemented. Optional groups would not be bundled by default. See @mislav's comment.

Provided this would not add any complexity, I'd 👍 this.

@myabc

This comment has been minimized.

Show comment
Hide comment
@myabc

myabc Mar 21, 2012

Contributor

@mitfik It's not implemented.

@parndt Use case for Refinery might be if you wanted to distribute an "out-of-the-box" deployable repo, rather than the current setup where you have to generate an application. This is what I (tried to) explain in my blog post on Bundler Pain Points.

Contributor

myabc commented Mar 21, 2012

@mitfik It's not implemented.

@parndt Use case for Refinery might be if you wanted to distribute an "out-of-the-box" deployable repo, rather than the current setup where you have to generate an application. This is what I (tried to) explain in my blog post on Bundler Pain Points.

@yfeldblum

This comment has been minimized.

Show comment
Hide comment
@yfeldblum

yfeldblum Mar 21, 2012

+1 for --with

I am in favor of the --with remembered configuration, because many of us have test-only, development-only, debug-only, and XYZ-only gems in our Gemfiles in appropriately-named groups, but who deploy with only the production and assets groups always and everywhere. --without development:test:debug:xyz:abc is more a problem to remember and configure than is --with [default:]assets:production. (This is obviously an example suited to Rails applications, but the general point is general.) Every application gets deployed with production and assets, and never with development, test, debug, xyz, and abc, which are usually different per-application, so --with is simpler and will be more universal than --without for many cases.

-1 for --condition

Deployable repos are a problem. We should not be using deployable repos.

The reason is that we should not all be forking Redmine just because we want to customize the contents of config/initializers/session_store.rb. We should have our own minimal concrete app for that.

We should generate an application rather than use a deployable repo.

The easiest approach, which should work for any modern app, is rails new new-redmine-app-directory and then add gem "redmine" to the Gemfile. All of the controllers, views, models, routes, assets, etc., from Redmine should be available and work in the new app.

The better approach, which requires the upstream project to make it happen, is as follows: the project, which should be distributed as a gem and which should include a binary for generating apps, should generate Gemfile, Gemfile.lock, and config.ru for you via a command-line generator program. E.g., redmine-app new new-redmine-app-directory. They may generate other things too, such as config/database.yml, config/environments/*.rb, Rakefile, etc., depending on whatever the application-as-gem author desires and what is appropriate for that application. For example, that could be switched with --full-rails-app-template or something, which perhaps asks you some questions like which database driver you want and then customizes the Gemfile for you. Ideally, Rails would have stuff to make this approach easy to do.

yfeldblum commented Mar 21, 2012

+1 for --with

I am in favor of the --with remembered configuration, because many of us have test-only, development-only, debug-only, and XYZ-only gems in our Gemfiles in appropriately-named groups, but who deploy with only the production and assets groups always and everywhere. --without development:test:debug:xyz:abc is more a problem to remember and configure than is --with [default:]assets:production. (This is obviously an example suited to Rails applications, but the general point is general.) Every application gets deployed with production and assets, and never with development, test, debug, xyz, and abc, which are usually different per-application, so --with is simpler and will be more universal than --without for many cases.

-1 for --condition

Deployable repos are a problem. We should not be using deployable repos.

The reason is that we should not all be forking Redmine just because we want to customize the contents of config/initializers/session_store.rb. We should have our own minimal concrete app for that.

We should generate an application rather than use a deployable repo.

The easiest approach, which should work for any modern app, is rails new new-redmine-app-directory and then add gem "redmine" to the Gemfile. All of the controllers, views, models, routes, assets, etc., from Redmine should be available and work in the new app.

The better approach, which requires the upstream project to make it happen, is as follows: the project, which should be distributed as a gem and which should include a binary for generating apps, should generate Gemfile, Gemfile.lock, and config.ru for you via a command-line generator program. E.g., redmine-app new new-redmine-app-directory. They may generate other things too, such as config/database.yml, config/environments/*.rb, Rakefile, etc., depending on whatever the application-as-gem author desires and what is appropriate for that application. For example, that could be switched with --full-rails-app-template or something, which perhaps asks you some questions like which database driver you want and then customizes the Gemfile for you. Ideally, Rails would have stuff to make this approach easy to do.

@mpapis

This comment has been minimized.

Show comment
Hide comment
@mpapis

mpapis Mar 21, 2012

👍 for @mislav's suggestion

mpapis commented Mar 21, 2012

👍 for @mislav's suggestion

@sickill

This comment has been minimized.

Show comment
Hide comment
@sickill

sickill commented Mar 22, 2012

+1 for @mislav's way

@aarek

This comment has been minimized.

Show comment
Hide comment
@aarek

aarek Mar 22, 2012

+1 for @mislav's suggestion

aarek commented Mar 22, 2012

+1 for @mislav's suggestion

@matee911

This comment has been minimized.

Show comment
Hide comment
@matee911

matee911 Mar 22, 2012

👍
+1 for @mislav's solution

matee911 commented Mar 22, 2012

👍
+1 for @mislav's solution

@lukaszsagol

This comment has been minimized.

Show comment
Hide comment
@lukaszsagol

lukaszsagol commented Mar 22, 2012

👍 @mislav ftw

@darthdeus

This comment has been minimized.

Show comment
Hide comment
@darthdeus

darthdeus commented Mar 22, 2012

+1 for @mislav

@nicholaides

This comment has been minimized.

Show comment
Hide comment
@nicholaides

nicholaides Mar 22, 2012

This would be very useful.

nicholaides commented Mar 22, 2012

This would be very useful.

@Vanuan

This comment has been minimized.

Show comment
Hide comment
@Vanuan

Vanuan Mar 22, 2012

Seems like bundler's authors do know better what users want: #1772

Vanuan commented Mar 22, 2012

Seems like bundler's authors do know better what users want: #1772

@mpapis

This comment has been minimized.

Show comment
Hide comment
@mpapis

mpapis Mar 22, 2012

@Vanuan yes they do, that's why I have this two projects: rubygems-bundler and mpapis-bundler(deprecated)

mpapis commented Mar 22, 2012

@Vanuan yes they do, that's why I have this two projects: rubygems-bundler and mpapis-bundler(deprecated)

@ryansch

This comment has been minimized.

Show comment
Hide comment
@ryansch

ryansch commented Mar 22, 2012

Sigh.

@Vanuan

This comment has been minimized.

Show comment
Hide comment
@Vanuan

Vanuan Mar 23, 2012

+1 for @yfeldblum suggestion, but @mislav's is also fine.

Vanuan commented Mar 23, 2012

+1 for @yfeldblum suggestion, but @mislav's is also fine.

@taylor

This comment has been minimized.

Show comment
Hide comment

taylor commented Mar 25, 2012

+1 @mislav

@namxam

This comment has been minimized.

Show comment
Hide comment
@namxam

namxam Apr 3, 2012

+1 for @mislav solution

namxam commented Apr 3, 2012

+1 for @mislav solution

@chrisberkhout

This comment has been minimized.

Show comment
Hide comment
@chrisberkhout

chrisberkhout Jun 27, 2012

+1 @mislav solution, but with different wording:

:default => false instead of :optional => true

chrisberkhout commented Jun 27, 2012

+1 @mislav solution, but with different wording:

:default => false instead of :optional => true

@skryl

This comment has been minimized.

Show comment
Hide comment
@skryl

skryl commented Nov 12, 2012

+1 @mislav

@pdf

This comment has been minimized.

Show comment
Hide comment
@pdf

pdf Jul 26, 2013

I'm sure there'd be a PR for this pretty promptly if there was any suggestion that work would be accepted, so 2.5 years on, any indication one way or the other would be greatly appreciated.

pdf commented Jul 26, 2013

I'm sure there'd be a PR for this pretty promptly if there was any suggestion that work would be accepted, so 2.5 years on, any indication one way or the other would be greatly appreciated.

@indirect

This comment has been minimized.

Show comment
Hide comment
@indirect

indirect Jul 26, 2013

Member

If you think it's that easy to support conditional gems, please implement it so people can try it. I'm not going to blanket ly accept or reject something that can't even be tested because it doesn't exist yet.

On Fri, Jul 26, 2013 at 3:33 AM, Peter Fern notifications@github.com
wrote:

I'm sure there'd be a PR for this pretty promptly if there was any suggestion that work would be accepted, so 2.5 years on, any indication one way or the other would be greatly appreciated.

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

Member

indirect commented Jul 26, 2013

If you think it's that easy to support conditional gems, please implement it so people can try it. I'm not going to blanket ly accept or reject something that can't even be tested because it doesn't exist yet.

On Fri, Jul 26, 2013 at 3:33 AM, Peter Fern notifications@github.com
wrote:

I'm sure there'd be a PR for this pretty promptly if there was any suggestion that work would be accepted, so 2.5 years on, any indication one way or the other would be greatly appreciated.

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

@xaviershay

This comment has been minimized.

Show comment
Hide comment
@xaviershay

xaviershay Aug 11, 2013

Contributor

Closing this.

  1. Read this comment from @indirect on another issue: #1771 (comment)
  2. No-one on the core team is going to work on this. A patch would be considered only if it explicitly addressed the above comment and other -1's on this thread.
  3. A +1 with no additional context is not useful. Always add how it would help you specifically. Are you trying to do the same thing that we do not recommend (such as asking users to run bundle install)? Do you have a different use case? Could your daily workflow be nicer?
  4. Please continue any discussion at https://github.com/bundler/bundler-features (do link back to this thread).
Contributor

xaviershay commented Aug 11, 2013

Closing this.

  1. Read this comment from @indirect on another issue: #1771 (comment)
  2. No-one on the core team is going to work on this. A patch would be considered only if it explicitly addressed the above comment and other -1's on this thread.
  3. A +1 with no additional context is not useful. Always add how it would help you specifically. Are you trying to do the same thing that we do not recommend (such as asking users to run bundle install)? Do you have a different use case? Could your daily workflow be nicer?
  4. Please continue any discussion at https://github.com/bundler/bundler-features (do link back to this thread).

@xaviershay xaviershay closed this Aug 11, 2013

@chrisberkhout

This comment has been minimized.

Show comment
Hide comment
@chrisberkhout

chrisberkhout Aug 11, 2013

@xaviershay Did I understand correctly that you recommend against having users run bundle install? Can you please point me to an explanation of that? I couldn't figure it out from http://bundler.io/.

chrisberkhout commented Aug 11, 2013

@xaviershay Did I understand correctly that you recommend against having users run bundle install? Can you please point me to an explanation of that? I couldn't figure it out from http://bundler.io/.

@pdf

This comment has been minimized.

Show comment
Hide comment
@pdf

pdf Aug 11, 2013

FWIW, I think the idea that bundler is only for developers is arbitrary, and a little bit silly. Anyone who can follow instructions, or has deployed a web application from source should be able to use it as instructed, and for any project that it doesn't make sense to package as a gem, bundler provides simple dependency resolution, with the execution of one command. There doesn't seem to be a lot of sense in forcing people to layer additional technology on top of it to avoid minor feature additions. Why shouldn't end users be expected to run bundle install? If you look at pretty much any Ruby web application (and a bunch of others), you'll note that executing bundler is a standard deployment step, and giving the user (and target users are up to the developer, often the target audience is technically competent) the ability to selectively enable dependencies would be useful.

Especially when the burden of the alternatives is pretty heavy - packaging for a dozen Linux distributions, plus Windows and OSX is a lot of development and testing overhead that doesn't need to exist, since all those packaging methods have their own foibles. Big shops can maybe justify the development cost, or dictate a very narrow list supported environments, but that's not going to work for a lot of people. And Capistrano has it's problems too, in fact I'd be significantly more reluctant to put Capistrano into the hands of end users than git and bundler.

pdf commented Aug 11, 2013

FWIW, I think the idea that bundler is only for developers is arbitrary, and a little bit silly. Anyone who can follow instructions, or has deployed a web application from source should be able to use it as instructed, and for any project that it doesn't make sense to package as a gem, bundler provides simple dependency resolution, with the execution of one command. There doesn't seem to be a lot of sense in forcing people to layer additional technology on top of it to avoid minor feature additions. Why shouldn't end users be expected to run bundle install? If you look at pretty much any Ruby web application (and a bunch of others), you'll note that executing bundler is a standard deployment step, and giving the user (and target users are up to the developer, often the target audience is technically competent) the ability to selectively enable dependencies would be useful.

Especially when the burden of the alternatives is pretty heavy - packaging for a dozen Linux distributions, plus Windows and OSX is a lot of development and testing overhead that doesn't need to exist, since all those packaging methods have their own foibles. Big shops can maybe justify the development cost, or dictate a very narrow list supported environments, but that's not going to work for a lot of people. And Capistrano has it's problems too, in fact I'd be significantly more reluctant to put Capistrano into the hands of end users than git and bundler.

@mislav

This comment has been minimized.

Show comment
Hide comment
@mislav

mislav Aug 11, 2013

Contributor

Agreed with @xaviershay that users shouldn't be running bundle install. And if Bundler maintainers say so, then that reflects the philosophy of Bundler project, and arguing their logic is a waste of breath.

Optional Gemfile groups could be useful to developers as a way of expressing soft dependencies, but until someone comes with a solid patch, I don't think there's sense in debating this further. Code is more powerful than words.

Contributor

mislav commented Aug 11, 2013

Agreed with @xaviershay that users shouldn't be running bundle install. And if Bundler maintainers say so, then that reflects the philosophy of Bundler project, and arguing their logic is a waste of breath.

Optional Gemfile groups could be useful to developers as a way of expressing soft dependencies, but until someone comes with a solid patch, I don't think there's sense in debating this further. Code is more powerful than words.

@pdf

This comment has been minimized.

Show comment
Hide comment
@pdf

pdf Aug 11, 2013

I'm yet to hear a solid explanation of why users should not be running bundle install. If debating the logic of an opinion is a waste of breath, that's a pretty said state of affairs.

pdf commented Aug 11, 2013

I'm yet to hear a solid explanation of why users should not be running bundle install. If debating the logic of an opinion is a waste of breath, that's a pretty said state of affairs.

@xaviershay

This comment has been minimized.

Show comment
Hide comment
@xaviershay

xaviershay Aug 11, 2013

Contributor

From the comment I linked to:

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.

As for the why:

  1. It clearly doesn't work as evidenced by this issue. It was not designed to do the things it needs to do for it to work well.
  2. It is not a pattern we want to encourage. It is not a great UX to have users need to know about and run an extra command.

Optional Gemfile groups could be useful to developers as a way of expressing soft dependencies, but until someone comes with a solid patch, I don't think there's sense in debating this further. Code is more powerful than words.

This.

These are strong opinions, weakly held. If anyone wants to work out a patch we can consider it.

I think the idea that bundler is only for developers is arbitrary, and a little bit silly.

Even if that is true, I don't see it as a problem. If we tried to solve every problem under the sun we'd have no chance of maintaining the project or delivering a good product for the 90% case of what people normally use it for.

Contributor

xaviershay commented Aug 11, 2013

From the comment I linked to:

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.

As for the why:

  1. It clearly doesn't work as evidenced by this issue. It was not designed to do the things it needs to do for it to work well.
  2. It is not a pattern we want to encourage. It is not a great UX to have users need to know about and run an extra command.

Optional Gemfile groups could be useful to developers as a way of expressing soft dependencies, but until someone comes with a solid patch, I don't think there's sense in debating this further. Code is more powerful than words.

This.

These are strong opinions, weakly held. If anyone wants to work out a patch we can consider it.

I think the idea that bundler is only for developers is arbitrary, and a little bit silly.

Even if that is true, I don't see it as a problem. If we tried to solve every problem under the sun we'd have no chance of maintaining the project or delivering a good product for the 90% case of what people normally use it for.

gonzalo-bulnes referenced this issue in gonzalo-bulnes/cucumber-api-steps Oct 20, 2013

Remove Ruby 1.9.2 support (as activesupport did)
The Travis build was broken because of the activesupport 4.0.0 dependency
on Ruby 1.9.3.
https://github.com/rails/rails/blob/4-0-stable/activesupport/activesupport.gemspec#L10

Specifying conditions on gem dependencies doesn't seem to be possible.
IMHO, deprecating ruby-1.9.2 in favor of supporting rails-4.0.0 and ruby-2.0.0
is the right thing to do.
@bigtunacan

This comment has been minimized.

Show comment
Hide comment
@bigtunacan

bigtunacan Oct 30, 2014

Ok; so I thought conditional gems were not supported, but just saw the following in one of my Gemfile's and ran bundle install to hit both the true and false clauses and it appears to be working correctly.

Did support for this get added at some point, or has this always worked, or is this somehow broken and I'm just losing my sanity and not seeing what is wrong here?

if ['development', ''].include?(ENV['RAILS_ENV'].to_s) || RUBY_PLATFORM =~ /darwin/i
   gem 'cups', '0.1.9'
else
   gem 'cups', '0.1.8'
end

bigtunacan commented Oct 30, 2014

Ok; so I thought conditional gems were not supported, but just saw the following in one of my Gemfile's and ran bundle install to hit both the true and false clauses and it appears to be working correctly.

Did support for this get added at some point, or has this always worked, or is this somehow broken and I'm just losing my sanity and not seeing what is wrong here?

if ['development', ''].include?(ENV['RAILS_ENV'].to_s) || RUBY_PLATFORM =~ /darwin/i
   gem 'cups', '0.1.9'
else
   gem 'cups', '0.1.8'
end
@jhass

This comment has been minimized.

Show comment
Hide comment
@jhass

jhass Oct 30, 2014

Contributor

@bigtunacan This will fail when the lock is committed in development/on an OS X box and then in production bundle install --deployment is run. It will also mean that in production there always will be a dirty git repository, preventing pulls that change the lock.

Contributor

jhass commented Oct 30, 2014

@bigtunacan This will fail when the lock is committed in development/on an OS X box and then in production bundle install --deployment is run. It will also mean that in production there always will be a dirty git repository, preventing pulls that change the lock.

@bigtunacan

This comment has been minimized.

Show comment
Hide comment
@bigtunacan

bigtunacan Oct 30, 2014

@jhass, thank you, I knew I ran in to problems with this before, but it's been so long I couldn't recall why.

bigtunacan commented Oct 30, 2014

@jhass, thank you, I knew I ran in to problems with this before, but it's been so long I couldn't recall why.

@steakknife

This comment has been minimized.

Show comment
Hide comment
@steakknife

steakknife Feb 12, 2015

Another method of expressing a gem's (as opposed to a project's) soft dependencies that are not platform-specific here

steakknife commented Feb 12, 2015

Another method of expressing a gem's (as opposed to a project's) soft dependencies that are not platform-specific here

steakknife added a commit to steakknife/rails_plus_hacks_and_threads that referenced this issue Feb 13, 2015

Update Gemfile
Conditional expressions in Gemfiles breaks `gem package --all` and others :(  There's open proposals to fix this here:

  - bundler/bundler-features#77
  - bundler/bundler-features#68
  - bundler/bundler#1636
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment