Default to printing a help message when bundle is run without arguments on 2.0
#5725
Conversation
|
I like this. As further evidence on the "should display help" side, most unix utilities (grep, etc) also print their help when they are run without arguments. |
|
my 2 cents would be to leave this on |
|
@chrismo I have gone back and forth on this for that reason... fwiw, My personal shell aliases are already |
|
I'm with @chrismo on this. "We've" trained people to use In this case, I ask myself why is this change better, and my answer is to help newbies who don't know how to use it for the first few days. This is not the best reason in my opinion. Some learning curves are acceptable and in this case having to learn that As far as being consistent with other package managers, well then I'd ask are all the other commands consistent with other package managers? If yes, then ok. If not, then it weakens your selling point as to why this change is better (to me anyway). So other than the above reasons, I ask why is this change really beneficial to bundler users? Is there a huge issue with newbies getting confused that outweighs the benefit to those who are proficient? Is it so important to be consistent with other package managers because all the other commands of bundler are consistent? Is there a future benefit where this is a small step to that direction that will make all this change so much more worthwhile in hindsight? These are all my thoughts and opinions on seeing this and having strong compelling reasons to the above questions help me decide on features otherwise I'd be catering to everyone. @indirect and @segiddins, I'm sure you've already thought through all of this and whichever way you decide, it'll be ok. Best of luck. 😃 |
|
@hmistry in the end, I think both OSS in general (and Bundler in this particular case) make things easier for experienced devs at the cost of new or interested devs. I believe that status quo is actively bad: experienced devs can either run |
|
@bundlerbot r+ |
|
📌 Commit 55d7283 has been approved by |
Default to printing a help message when `bundle` is run without arguments on 2.0 ### What was the end-user problem that led to this PR? The problem was that users unfamiliar with Bundler would run `bundle` and either install gems (if in a directory with a gemfile), or else get the error `Could not locate Gemfile`. You'd need to know to run `bundle help` or `bundle -h` to get the man page, and even that could be overwhelming (not to mention turfing you into a pager). ### Was was your diagnosis of the problem? My diagnosis was that we ought to print some form of help when the bare `bundle` command is run, rather than defaulting to running `bundle install`. This work was prompted by https://trello.com/c/OpuOdTZl/112-print-help-when-bundle-is-run-without-arguments, and is an improvement (rather than a straight port) on #3831. ### What is your fix for the problem, implemented in this PR? My fix was to print the following help output when the CLI is invoked without arguments, contingent upon a feature flag. ``` Bundler version 1.15.1 Commands: bundle add GEM VERSION # Add gem to Gemfile and run bundle install bundle binstubs GEM [OPTIONS] # Install the binstubs of the listed gem bundle check [OPTIONS] # Checks if the dependencies listed in Gemfile are satisfied by currently installed gems bundle clean [OPTIONS] # Cleans up unused gems in your bundler directory bundle config NAME [VALUE] # retrieve or set a configuration value bundle console [GROUP] # Opens an IRB session with the bundle pre-loaded bundle doctor [OPTIONS] # Checks the bundle for common problems bundle env # Print information about the environment Bundler is running under bundle exec [OPTIONS] # Run the command in context of the bundle bundle gem GEM [OPTIONS] # Creates a skeleton for creating a rubygem bundle help [COMMAND] # Describe available commands or one specific command bundle help [COMMAND] # Describe subcommands or one specific subcommand bundle info GEM [OPTIONS] # Show information for the given gem bundle init [OPTIONS] # Generates a Gemfile into the current working directory bundle inject GEM VERSION # Add the named gem, with version requirements, to the resolved Gemfile bundle install PLUGINS # Install the plugin from the source bundle install [OPTIONS] # Install the current environment to the system bundle issue # Learn how to report an issue in Bundler bundle licenses # Prints the license of all gems in the bundle bundle lock # Creates a lockfile without installing bundle open GEM # Opens the source directory of the given bundled gem bundle outdated GEM [OPTIONS] # list installed gems with newer versions available bundle package [OPTIONS] # Locks and then caches all of the gems into vendor/cache bundle platform [OPTIONS] # Displays platform compatibility information bundle plugin SUBCOMMAND ...ARGS # manage the bundler plugins bundle pristine # Restores installed gems to pristine condition from files located in the gem cache. Gem installed from a git repository will be issued `git checkout --force`. bundle show GEM [OPTIONS] # Shows all gems that are part of the bundle, or the path to a given gem bundle update [OPTIONS] # update the current environment bundle version # Prints the bundler's version information bundle viz [OPTIONS] # Generates a visual dependency graph Options: [--no-color] # Disable colorization in output -r, [--retry=NUM] # Specify the number of times you wish to attempt network commands -V, [--verbose], [--no-verbose] # Enable verbose output mode ``` ### Why did you choose this fix out of the possible options? I chose this fix because it aligns the Bundler CLI with many other package managers that display a help message of some sort when invoked without arguments: - CocoaPods - npm - RubyGems - Homebrew - pip - Swift Package Manager - Carthage - Cargo And unlike the following, which _do_ install by default: - yarn As to the particular format of the help printed, I thought something concise would be less disruptive than the full man page. Improvements to the output would be welcome, this is just using the Thor default right now but we can easily implement our own. This will require test coverage, but I thought I'd hold off until the general change got some buy-in.
|
☀️ Test successful - status-travis |
What was the end-user problem that led to this PR?
The problem was that users unfamiliar with Bundler would run
bundleand either install gems (if in a directory with a gemfile), or else get the errorCould not locate Gemfile. You'd need to know to runbundle helporbundle -hto get the man page, and even that could be overwhelming (not to mention turfing you into a pager).Was was your diagnosis of the problem?
My diagnosis was that we ought to print some form of help when the bare
bundlecommand is run, rather than defaulting to runningbundle install.This work was prompted by https://trello.com/c/OpuOdTZl/112-print-help-when-bundle-is-run-without-arguments, and is an improvement (rather than a straight port) on #3831.
What is your fix for the problem, implemented in this PR?
My fix was to print the following help output when the CLI is invoked without arguments, contingent upon a feature flag.
Why did you choose this fix out of the possible options?
I chose this fix because it aligns the Bundler CLI with many other package managers that display a help message of some sort when invoked without arguments:
And unlike the following, which do install by default:
As to the particular format of the help printed, I thought something concise would be less disruptive than the full man page.
Improvements to the output would be welcome, this is just using the Thor default right now but we can easily implement our own. This will require test coverage, but I thought I'd hold off until the general change got some buy-in.