Support Git and Github Shortcuts

[yfeldblum]

Git Shortcuts

The shortcut for the :ref option can be the URI fragment.

>>> dependency name, git: "/path/to/repo#ref"
#=> dependency name, git: "/path/to/repo", ref: "ref"

Github Shortcuts

Like Bundler's shortcuts.

>>> dependency name, github: "org/repo"
#=> dependency name, git: "https://github.com/org/repo"

>>> dependency name, github: "repo"
#=> dependency name, git: "https://github.com/repo/repo"

Hedgehog

/cc @hedgehog

Aggregating the two above.

>>> cookbook name, github: "cookbooks/name#qa"
#=> cookbook name, git: "https://github.com/cookbooks/name", ref: "qa"

Path Option

This is an open question: should there be some shortcut for the :path option for the Git source? What would it look like?

[hedgehog]

Sorry I've not been more active on these topics - otherwise swamped.
The shortcut ideas are nice.
In what follows I'm assuming a production context once more.
Some additional thoughts....

To DRY things out, maybe allow methods that set a global, and arbitrary, default git: 'root-fragment' and ref:. Example:

git "https://github.com/other"
cookbook name, git: "name2", ref: "qa"
cookbook name, git: "name2", ref: "qa"
ref "master"
git "https://github.com/cookbooks"
cookbook name, git: "name3"
...
cookbook name, git: "name13"

To really get flexible, the git and ref methods could accept blocks that return a string - allowing people additional felxibility, e.g. setting the ref and git root based on, say, and environment variable.

HTH

[yfeldblum]

Since Cheffile (and every specfile) is pure Ruby, there's no reason to support any special syntax for procs. Setting a local variable in one place (e.g., a common ref or a value based on an environment variable) and using it below is supported a priori because it's just Ruby, as is computing an expression inline. Overall, however, the spec declared by a specfile should typically be completely deterministic and should not change based on any such factors like environment variables. Computation in a specfile should typically be done for shortcuts, rather than for switching.

The way git sources work now is that each fully-formed combination of (uri, ref, path) is its own independent source, with no sharing (which blocks having a default git source which is actually a github organization plus a default ref). It is this way because Bundler works this way, and being similar to Bundler is an explicit goal, at least at the specfile/lockfile level as well as at the level of what is a source. So this would require a new type of source, such as a git_site source.

[hedgehog]

Ack. It has been a while since I delved into the code so had forgotten that any Ruby is legitimate. All looks nice.
You do raise some points that suggest a 'best-practices/lessons-learned' list might be a useful addition to the readme or wiki.
Thanks for all the great work in laying this foundation.