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
- Add minimal go.mod, go.sum. The intention is to make it so that it's possible to import and use this package from within Go modules (in addition to the well-supported GOPATH workspace mode), and have... — committed to shurcooL/github_flavored_markdown by dmitshur 6 years ago
- Add minimal go.mod, go.sum. (#22) The intention is to make it so that it's possible to import and use this package from within Go modules (in addition to the well-supported GOPATH workspace mode), ... — committed to shurcooL/github_flavored_markdown by dmitshur 6 years ago
this sounds reasonable to me (as i noted over on the other issue) 👍
🎉 🎉
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:
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
.this would be an appropriate alternative to overrides for @markbates to exercise in his project. adding the
required
bit is equivalent to directly importinggithub.com/russross/blackfriday
- dep now considers it a direct dependency, so he can constrain it himself in hisGopkg.toml
however, because this project DOES import
github.com/russross/blackfriday
, there’d be no need for @shurcooL to add it in aGopkg.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
atgopkg.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.
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
?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:
If you run
dep init
on it you get the following in the Gopkg.lock file:Then, of course, it won’t build:
I believe, and I might be mistaken, if you add a
Gopkg.toml
like this: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 themaster
branch of blackfriday.