converts project to use dep

[zevdg]

As discussed in #28
Ok, so switching to dep itself was fairly straightforward. As for the dependency changes:

• github.com/shurcooL/sanitized_anchor_name was updated a few commits, but the code hasn't changed at all
• github.com/russross/blackfriday actually got downgraded several commits because the last v1.x release is relatively old and by default, dep prefers tagged semver releases.

I could have change the dep constraint to ignore semver and just track the master branch to avoid this downgrade, but that felt dirty. Instead, I asked them to roll a new v1 release at russross/blackfriday#383 (comment)

I'd recommend holding off on merging this until they respond there to avoid any potential regressions that could result from downgrading that dependency.

[rtfb]

1.5 released: https://github.com/russross/blackfriday/releases/tag/v1.5.

[zevdg]

updated to v1.5 by simply running dep ensure -update and committing. Interestingly, the sanitized_anchor_name dependency got swallowed by blackfriday at the request of @adg under russross/blackfriday#350, so your dep graph is super simple now.

[zevdg]

If you haven't been following dep closely, this line may surprise you. In other package managers, this would look like I'd pinned you specifically to v1.4 and yet somehow, the lock file now shows v1.5. In dep, undecorated constraints are implicitly carot requirements. So this line really means 1.4 <= version < 2.0.0 which is essentially what we want. dep ensure -update respects the existing manifest and only updates the lockfile and vendor folder.

[cpuguy83]

LGTM, thanks!

[zevdg]

FYI, @cpuguy83 you'll need to tag a new release in order to fully resolve this problem. downstream dep users still break on this because they pull in your latest tagged release ( v1.0.6) which does't have this change.

[cpuguy83]

@zevdg Thanks for pointing that out! I've tagged a new release (v1.0.7)