github_flavored_markdown: Doesn't build in projects that use `dep` Go dependency management tool due to issue with blackfriday v2.0.0 tag.

They released blackfriday v2, about 20 hours ago, and now this project doesn’t build anymore. 😦

vendor/github.com/shurcooL/github_flavored_markdown/main.go:82: undefined: blackfriday.EXTENSION_NO_INTRA_EMPHASIS
vendor/github.com/shurcooL/github_flavored_markdown/main.go:83: undefined: blackfriday.EXTENSION_TABLES
vendor/github.com/shurcooL/github_flavored_markdown/main.go:84: undefined: blackfriday.EXTENSION_FENCED_CODE
vendor/github.com/shurcooL/github_flavored_markdown/main.go:85: undefined: blackfriday.EXTENSION_AUTOLINK
vendor/github.com/shurcooL/github_flavored_markdown/main.go:86: undefined: blackfriday.EXTENSION_STRIKETHROUGH
vendor/github.com/shurcooL/github_flavored_markdown/main.go:87: undefined: blackfriday.EXTENSION_SPACE_HEADERS
vendor/github.com/shurcooL/github_flavored_markdown/main.go:88: undefined: blackfriday.EXTENSION_NO_EMPTY_LINE_BEFORE_BLOCK
vendor/github.com/shurcooL/github_flavored_markdown/main.go:88: const initializer blackfriday.EXTENSION_NO_INTRA_EMPHASIS | blackfriday.EXTENSION_TABLES | blackfriday.EXTENSION_FENCED_CODE | blackfriday.EXTENSION_AUTOLINK | blackfriday.EXTENSION_STRIKETHROUGH | blackfriday.EXTENSION_SPACE_HEADERS | blackfriday.EXTENSION_NO_EMPTY_LINE_BEFORE_BLOCK is not a constant
vendor/github.com/shurcooL/github_flavored_markdown/main.go:104: undefined: blackfriday.Html

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Comments: 23 (8 by maintainers)

Commits related to this issue

Most upvoted comments

this sounds reasonable to me (as i noted over on the other issue) 👍

Or I can start hacking on golang/dep#902 right away, but that would probably end up being a busier equivalent of waiting 😃

🎉 🎉

honestly, i don’t think it’d be that bad to do 😄 at least, not the additional parsing bits that #902 is focused on. incorporating a new satisfiability condition into the solver is trickier, but still probably pretty isolated - i’m happy to guide, or will do it myself if necessary.

hi folks!

@bpicode is definitely right - we can’t cover everything. we have to define some general rules, and one of those is preferring semver tags to branches. this is causing some growing pains now, but we expect that pain should largely subside once the community starts generating semver-tagged releases as a matter of course. the two cases it tends to hurt in are:

  1. when there’s just one or two really old semver releases
  2. when the first semver release gets made, and it’s incompatible with what was previously on the default branch (aka, this case)

@bpicode: Would it help if you define an override in Gopkg.toml?

an override would solve @markbates’ problem, but we do try to discourage their use if possible. the ideal solution, from dep’s perspective, is for this project to specify the a version constraint on github.com/russross/blackfriday.

I believe, and I might be mistaken, if you add a Gopkg.toml like this:

required = ["github.com/russross/blackfriday"]

[[constraint]]
  branch = "master"
  name = "github.com/russross/blackfriday"

at the root of this repo, it should fix the problem.

this would be an appropriate alternative to overrides for @markbates to exercise in his project. adding the required bit is equivalent to directly importing github.com/russross/blackfriday - dep now considers it a direct dependency, so he can constrain it himself in his Gopkg.toml

however, because this project DOES import github.com/russross/blackfriday, there’d be no need for @shurcooL to add it in a Gopkg.toml for this project. all that’s needed is the [[constraint]] stanza.

there are two other alternatives, as well. if this project starts importing blackfriday at gopkg.in/russross/blackfriday.v1 instead of directly from github, then dep may do the right thing, as i believe that’ll end up using master as the default branch, which i think will still be visited before the older tags blackfriday has.

blackfriday could also start using package import comments to enforce that its v2 is imported via gopkg.in - e.g.

package blackfriday // import "gopkg.in/russross/blackfriday.v2"

now, dep hasn’t actually added the support for this yet (golang/dep#902), because people largely haven’t reported needing it - but, i’d count this as such a report. anyway, what it will do is treat those package import comments as another satisfiability condition that must be met for a version to be acceptable.

the problem with this approach is that the v2.0.0 tag would need to be moved after introducing that comment, otherwise it’ll still be the one that dep finds when no further constraints are specified.

@shurcooL I’ve patched Buffalo to fix this, so my “immediate” need is gone, but it definitely feels like a hack to fix it there.

I love this project, and just want to make sure no one else runs into this problem.

@victorshinya There are no updates on this as far as I know.

My suggested workaround would be to use Go modules that were added in Go 1.11. This package fully supports them as of PR #22.

Thanks a lot for the detailed and informative response @sdboyer! I think that should be sufficient information for us to find a good upstream solution in blackfriday.

@markbates Drive-by comment:

Would it help if you define an override in Gopkg.toml?

[[override]]
  name = "github.com/russross/blackfriday"
  version = "1.4.0"

Yeah, right now everyone who uses this package and dep is going to have problems, unless they do a manual import of blackfriday and then lock the constraint down themselves.

Take this application:

package main

import _ "github.com/shurcooL/github_flavored_markdown"

func main() {
}

If you run dep init on it you get the following in the Gopkg.lock file:

[[projects]]
  name = "github.com/russross/blackfriday"
  packages = ["."]
  revision = "cadec560ec52d93835bf2f15bd794700d3a2473b"
  version = "v2.0.0"

Then, of course, it won’t build:

# github.com/gobuffalo/depp/vendor/github.com/shurcooL/github_flavored_markdown
vendor/github.com/shurcooL/github_flavored_markdown/main.go:82: undefined: blackfriday.EXTENSION_NO_INTRA_EMPHASIS
vendor/github.com/shurcooL/github_flavored_markdown/main.go:83: undefined: blackfriday.EXTENSION_TABLES
vendor/github.com/shurcooL/github_flavored_markdown/main.go:84: undefined: blackfriday.EXTENSION_FENCED_CODE
vendor/github.com/shurcooL/github_flavored_markdown/main.go:85: undefined: blackfriday.EXTENSION_AUTOLINK
vendor/github.com/shurcooL/github_flavored_markdown/main.go:86: undefined: blackfriday.EXTENSION_STRIKETHROUGH
vendor/github.com/shurcooL/github_flavored_markdown/main.go:87: undefined: blackfriday.EXTENSION_SPACE_HEADERS
vendor/github.com/shurcooL/github_flavored_markdown/main.go:88: undefined: blackfriday.EXTENSION_NO_EMPTY_LINE_BEFORE_BLOCK
vendor/github.com/shurcooL/github_flavored_markdown/main.go:88: const initializer blackfriday.EXTENSION_NO_INTRA_EMPHASIS | blackfriday.EXTENSION_TABLES | blackfriday.EXTENSION_FENCED_CODE | blackfriday.EXTENSION_AUTOLINK | blackfriday.EXTENSION_STRIKETHROUGH | blackfriday.EXTENSION_SPACE_HEADERS | blackfriday.EXTENSION_NO_EMPTY_LINE_BEFORE_BLOCK is not a constant
vendor/github.com/shurcooL/github_flavored_markdown/main.go:104: undefined: blackfriday.Html

I believe, and I might be mistaken, if you add a Gopkg.toml like this:

required = ["github.com/russross/blackfriday"]

[[constraint]]
  branch = "master"
  name = "github.com/russross/blackfriday"

at the root of this repo, it should fix the problem.

You don’t want to specify the v1 version, as that was cut a very long time ago and doesn’t reflect the master branch of blackfriday.