Add :gist option for gems embedded in gists

[jgaskins]

This PR allows the use of a :gist option to use gems embedded in Github gists: gem 'my-gem', gist: 1234567890 (either numeric or stringified).

I doubt that the use case for this would be too common, but this is a small convenience for sharing small gem prototypes.

[indirect]

How is it easier to share a gem prototype in a gist than in a git repo, though? We already have :github syntax, and you can create a gem prototype in a git repo like this:

bundle gem foo
cd foo
git commit -m 'new gem'
git create # uses `hub` from defunkt/hub
git push -u origin master

Is that actually harder than organizing a gist to contain multiple files?

[indirect]

Oh, and just in case it wasn't clear, you can use the gem created in the last comment in a Gemfile like this:

gem 'foo', :github => 'indirect/foo'

[travisbot]

This pull request passes (merged a3a3efa into 14a0648).

[rxbynerd]

I'm currently developing small (less-LOC-the-better) gems/rails extensions in gists because it's more lightweight, and the full repo doesn't show up on your resume

[jgaskins]

Small snippets of code are very commonly passed around in gists. If you wanted to create a gem out of it, you just need to add a gemspec, which is trivial. Also, creating gists from scratch is just as simple using defunkt/gist as creating Github repos is with defunkt/hub. ;-)

The point of this PR isn't to debate which method users should be using, though. I just wanted to give users the option of using gists. I've used gists in bundles before (like @Poptart said, they're inherently very lightweight, thanks to their single-directory structure) and while this is indeed a minor convenience, it's arguably as much of a convenience as the :github option.

[indirect]

@jgaskins, as you point out, you can (very) easily use gists in Bundles right now -- I'm not trying to argue that gems in gists are bad or anything like that. I would estimate that 85-95% of all git gems are from github, so the :github option seemed like a no-brainer. Furthermore, github repos are well-known by author and name. For example, if you want to use Rails from git, you know you can just type "rails".

The win of a :gist option is less clear to me: First, gists are identified by giant numbers that humans don't know off the top of their heads. Second, I can't figure out a use-case where you know the number of a gist but not the git url. Maybe you can explain when that is true, since this patch seemed worthwhile to you? Thanks.

[jgaskins]

I do agree with you that the mnemonic value of gist ids is nowhere near as high as it is for Github repos and that if you know the gist id, then you do know the URL. And since gists are mostly identified by links, you really only need to change the protocol from https => git and append .git to find the git endpoint. I agree with you on all of this.

This patch is meant to scratch two of my own minor itches, really. The first is identifying it as a git repo. I feel that copying the numeric value to a file is easier than copying and then editing the gist URL (and certainly faster than opening the link and copy/pasting the clone URL from the gist page) to point to a git repo rather than a web page. The second is in the expressiveness of this option; an entire URI to specify a gist is mostly noise. If we specify only the necessary amount of information to identify the source (the same as is done with the :github option), it's much easier to understand.

So, while I agree that we'd be unable to type in the gist id from memory the way we do when pointing to Github repos, I feel that that's the only objective advantage that the :github option has over this … besides maybe their more widespread use as a gem source. :-)

[indirect]

Typing things in from memory and widespread usage are the main reasons why I thought the :github option was a good idea... so you can possibly understand why I'm not totally sold on :gist. :) Honestly, this seems like a perfectly okay thing to have. I'm resisting because I've become worried about accruing more code, more options, more things that need documenting, more things that need testing, and more things that can possibly break in the future. All of those things increase the effort required to maintain Bundler, and I would like to keep that as low as possible. I'm probably going to accept this patch, but I'd like to consider it a little more before I do.

Thanks for submitting and discussing!

[jgaskins]

Oh I understand completely. I'm sure a lot of us are all too familiar with (and traumatized by) maintaining code that others have written. :-) I'm also aware that this is indeed a minor convenience at best so if you feel the cost/benefit ratio is too high, there won't be any hard feelings on my end.

There is a lot of room for improvement here, as well, and I'll look into it a little more. Not sure this PR is the best place for an in-depth discussion on it, but overall I think the DSL code could be cleaner and I'd like to clean it up enough that adding options like this won't scare you. I'll play with it some and hopefully we can chat about it again soon.

[timoschilling]

+1

[rohitarondekar]

Any change in the status of this PR? Or can it be closed?