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

"bundle" without any arguments is equivalent to "bundle install" #1452

Closed
sampablokuper opened this Issue Sep 26, 2011 · 7 comments

Comments

Projects
None yet
6 participants
@sampablokuper

sampablokuper commented Sep 26, 2011

It seems to be conventional that command line programs should execute, when called without arguments, only if they are nullipotent. For instance, the command ls executes when called without arguments, and this is both useful and also, because ls is nullipotent, safe.

If a command line program is not nullipotent, then its default behaviour when called without arguments should be to behave as though it has been called together with its help option. For instance, rm, when called without arguments, instead of deleting anything, lists the arguments it takes, much as if rm -h or rm --help had been called instead.

The bundle command, by contrast, when called without any arguments, behaves as though bundle install has been been called. That is, Bundler treats the bundle and bundle install commands as synonymous equivalents.

If this is intended behaviour, then the intention is questionable insofar as it breaks the command line conventions I've outlined above, to little advantage (a terser way of calling bundle install) and an obvious disadvantage (the possibility for a user to invoke bundler install unexpectedly and thereby install or reinstall a bundle of gems on his/her machine without having wished to do so).

@radar

This comment has been minimized.

Show comment
Hide comment
@radar

radar Sep 26, 2011

Contributor

Running bundle with no commands will generate a new bundle if you have not yet run bundle install in your project. The worst that this would do would install a couple of new gems, which could be removed with gem uninstall <gemname> -v <version> easily enough.

If you've already run bundle install/bundle, chances are that running bundle will do nothing more than state "Your bundle is complete", i.e. a nullipotent operation.

Changing this behaviour right now would be unhelpful for the users of Bundler who are familiar with it. Yes, it breaks command-line conventions, but I don't see any reason to change it now besides that.

Contributor

radar commented Sep 26, 2011

Running bundle with no commands will generate a new bundle if you have not yet run bundle install in your project. The worst that this would do would install a couple of new gems, which could be removed with gem uninstall <gemname> -v <version> easily enough.

If you've already run bundle install/bundle, chances are that running bundle will do nothing more than state "Your bundle is complete", i.e. a nullipotent operation.

Changing this behaviour right now would be unhelpful for the users of Bundler who are familiar with it. Yes, it breaks command-line conventions, but I don't see any reason to change it now besides that.

@indirect indirect closed this Sep 26, 2011

@indirect indirect reopened this Sep 26, 2011

@sampablokuper

This comment has been minimized.

Show comment
Hide comment
@sampablokuper

sampablokuper Sep 26, 2011

Thanks for reviewing the bug, Ryan.

It sounds like you agree bundle install is an idempotent command, not a
nullipotent one, and that the current behaviour of bundle breaks a
sensible and widespread convention concerning non-nullipotent programs.

Yet besides these rather compelling reasons, you see no cause to change the
behaviour, because some users of Bundler are familiar with it.

However, given that the number of (potential) users of Bundler who are used
to the sensible general conventions I outlined in the bug report likely
vastly outnumber the number of present users of Bundler who are familiar
with
the behaviour of bundler, and also given that anyone who wrote
software that relies upon the quirky behaviour of bundler should instead
have made that software rely upon the un-quirky behaviour of bundler install, your view does strike me as a little obstinate.

Surely the sooner this is fixed the smaller the number of inconvenienced
existing users will be. Also, the sooner it is fixed, the smaller the number
of new users will be who find that bundler violates (as it currently does)
the principle of least surprise.

sampablokuper commented Sep 26, 2011

Thanks for reviewing the bug, Ryan.

It sounds like you agree bundle install is an idempotent command, not a
nullipotent one, and that the current behaviour of bundle breaks a
sensible and widespread convention concerning non-nullipotent programs.

Yet besides these rather compelling reasons, you see no cause to change the
behaviour, because some users of Bundler are familiar with it.

However, given that the number of (potential) users of Bundler who are used
to the sensible general conventions I outlined in the bug report likely
vastly outnumber the number of present users of Bundler who are familiar
with
the behaviour of bundler, and also given that anyone who wrote
software that relies upon the quirky behaviour of bundler should instead
have made that software rely upon the un-quirky behaviour of bundler install, your view does strike me as a little obstinate.

Surely the sooner this is fixed the smaller the number of inconvenienced
existing users will be. Also, the sooner it is fixed, the smaller the number
of new users will be who find that bundler violates (as it currently does)
the principle of least surprise.

@indirect

This comment has been minimized.

Show comment
Hide comment
@indirect

indirect Sep 26, 2011

Member

I agree that bundle with no commands should display the help rather than install the bundle. However, since the Bundler team has agreed to conform to SemVer, this change will take place in Bundler 2.0.

Member

indirect commented Sep 26, 2011

I agree that bundle with no commands should display the help rather than install the bundle. However, since the Bundler team has agreed to conform to SemVer, this change will take place in Bundler 2.0.

@sampablokuper

This comment has been minimized.

Show comment
Hide comment
@sampablokuper

sampablokuper Sep 26, 2011

Thanks Andre, scheduling the fix for 2.0 to comply with SemVer sounds
reasonable.

sampablokuper commented Sep 26, 2011

Thanks Andre, scheduling the fix for 2.0 to comply with SemVer sounds
reasonable.

@dsjoerg

This comment has been minimized.

Show comment
Hide comment
@dsjoerg

dsjoerg May 16, 2013

Excellent, I was trying to figure out what bundle with no arguments did. Another reason to do this one is because currently "bundle --help" doesnt tell the user what calling with no args does.

dsjoerg commented May 16, 2013

Excellent, I was trying to figure out what bundle with no arguments did. Another reason to do this one is because currently "bundle --help" doesnt tell the user what calling with no args does.

@starkcoffee

This comment has been minimized.

Show comment
Hide comment
@starkcoffee

starkcoffee Jul 1, 2013

The nullipotent reason is a bit academic but probably correct. The more compelling reason is that since there are so many bundler commands, it's not completely obvious what it's behaviour is without arguments. I just had some beginners ask me what the difference is between 'bundle' and 'bundle install' and I never get this question with 'ls'

starkcoffee commented Jul 1, 2013

The nullipotent reason is a bit academic but probably correct. The more compelling reason is that since there are so many bundler commands, it's not completely obvious what it's behaviour is without arguments. I just had some beginners ask me what the difference is between 'bundle' and 'bundle install' and I never get this question with 'ls'

@xaviershay

This comment has been minimized.

Show comment
Hide comment
@xaviershay

xaviershay Aug 11, 2013

Contributor

Good idea, closing here (no more discussion needed, we use this tracker for bugs) but keeping on the v2 roadmap.

Contributor

xaviershay commented Aug 11, 2013

Good idea, closing here (no more discussion needed, we use this tracker for bugs) but keeping on the v2 roadmap.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment