Add option to plugin install for local plugins

[kerrizor]

I ran into this when working on bundler-dependency_graph bundle plugin currently supports --git and --source (rubygems) options, which both expect a URL. I had mixed success providing it with a file:// URL, but a full-fledged --file option that accepted a filepath would've sped things along.

[64kramsystem]

@kerrizor could you give more specifics about "mixed success"? I had a look a the code, and a solution; I was wondering if the proposed --file is in essence an internal conversion of the file path to the corresponding URI, or if there are more complex cases.

[64kramsystem]

I've just reviewed my PR, and found that the --git param of the plugin install command actually does support filepaths, even with spaces, eg.:

bin/bundle plugin install --git '/home/myuser/workspace/bundler dependency graph' bundler-dependency_graph

So definitely need a test case from @kerrizor (unless I'm missing something obvious 🤔 😄).

For reference, I've tested this from master (007a173).

[kerrizor]

@saveriomiroddi I honestly don't recall what I meant by "mixed success" - it was a year ago! Perhaps it is related to the the issue I mentioned in rubygems/bundler#5446 ? IIRC even the file:// installs checked the caching and wouldn't (re)load the local files when you rerun bundle plugin install, which frankly was surprising.

The use of file:// as a valid URL honestly surprised me; I know that it is valid, it just isn't something I see terribly often, so it wasn't an immediately obvious solution to the problem (nor to the dozen or so people I pinged on slack/twitter to check if it was obvious and I just missed it) so an option that accepted a relative or absolute file explicitly, without dropping support for file:// seemed like a user-friendly addition.

[64kramsystem]

@kerrizor given that the form --git /path/to/file works fine (again, unless I'm missing something; based on my understanding, the caching problem (#5446 is separate), I would classify this as a documentation problem - specifically, just extending the help:

$ bundle plugin install --help
Options:
  [--git=URL (`https://` or `git@`) or local path (`/path/to/repo`) of the git repo to fetch from]                       

would work. Of course, it assumes that the dev actually read the help 😄

However, usability is king, so I'm neutral to this.

[kerrizor]

hhhhuuuuhhhh I swear it didn't work when @roseaboveit and I were working on this, but again, it's been > a year!

[64kramsystem]

@kerrizor just to make it clear, with this:

Of course, it assumes that the dev actually read the help

I wasn't referring to you - I was trying to figure out a real-world case where the strategy of enhancing the help (opposed to introducing a new option) would fail, and I thought a case would be that of a hypothetical user reading the options, but not their help.

Sorry if there was a misunderstading 😄.

[kerrizor]

@saveriomiroddi no worries! I was laughing a bit at myself. :)

[jaredbeck]

I've also had "mixed success" with the "Running your plugin locally" section of the How to write a Bundler plugin instructions.

bundler plugin install my_plugin --source file:///Users/jared/git/my_plugin/ --verbose
Gem::RemoteFetcher::FetchError: Errno::ENOENT: 
\ No such file or directory @ rb_sysopen - /Users/jared/git/my_plugin/specs.4.8.gz
/Users/jared/..../rubygems/remote_fetcher.rb:274:in `rescue in fetch_path'
....

The instructions do not say anything about this mysterious specs.4.8.gz file 👻 .

Using --git instead of --source works, but the requirement to make a commit every time does slows down local development slightly.

[deivid-rodriguez]

We now have a proper --path option thanks to @ccutrer's work at #6960, so closing!