Cannot find module providing package gopkg.in/russross/blackfriday.v2

Getting Help
1

I’m using Go1.13. My project used gopkg.in/russross/blackfriday.v2 and before I initialized modules it worked. When modules was initialized by go mod init the project cannot run. I’ve go the following error:

go: finding gopkg.in/russross/blackfriday.v2 v2.0.1
go: finding gopkg.in/russross/blackfriday.v2 v2.0.1
build gitlab.com/edu/petstore/main: cannot load gopkg.in/russross/blackfriday.v2: cannot find module providing package gopkg.in/russross/blackfriday.v2

How can I solve it?

3 Likes
2

Have you tried following the instructions from the README to import directly from github:

It is go get -able via via gopkg.in at gopkg.in/russross/blackfriday.v2 , but we highly recommend using package management tool like [dep][7] or [Glide][8] and make use of semantic versioning. With package management you should import github.com/russross/blackfriday and specify that you’re using version 2.0.0.

2 Likes
3

Well, if gopackages is intended to replace all of those 3rd party dependency tools is not it overhaed to keep into the project another package management tool alogside with gopackages?

I would rather will find another option to replace that blackfriday if they even aren’t able to provide a usable mechanism to use the package.

2 Likes
4

Go modules got “invented” to obselete all those third party solutions, yes. Anyway, those that used gopkg.in or other third party solutions have decided to support it a long time ago and now pay the additional cost of legacy maintenance at least for a transition phase that can take several years, until go prior to 1.12 has disappeared from living linux distributions.

Tech debts, legacy support… Known concepts and big problems in the world of IT and hard to solve…

And I haven’t tried that package[*], but as you are already using go modules, have you tried to just use blackfriday by importing it from GitHub rather than gopkg.in?

[*] My current machine hasn’t a recent go available.

edit

And if you really have problems even using GitHub imports to get it running with Go modules, feel free to open a ticket at their repository. Go modules will eventually replace all other tools, as it is the officially provided tool. Everything else will remain a crutch…

2 Likes
5

I used it in a recommended way by go get and import "gopkg.in/russross/blackfriday.v2" But prior to modules.

Did you mean the same?

2 Likes
6

Your IP suggests you are using go modules, go modules is a tool to manage dependency versions, and the README asks you to import from GitHub when using such a tool. So have you tried importing from GitHub?

2 Likes
7

Now I imported from github and could use it in a simple project which uses modules.
But then I tried to use it alongside with md2pfd and it failed:

go: finding gopkg.in/russross/blackfriday.v2 v2.0.1
go: finding gopkg.in/russross/blackfriday.v2 v2.0.1
build command-line-arguments: cannot load gopkg.in/russross/blackfriday.v2: cannot find module providing package gopkg.in/russross/blackfriday.v2

my imports

    import (
    	"fmt"
    	"log"

	"github.com/mandolyte/mdtopdf"
	"github.com/microcosm-cc/bluemonday"
	"github.com/russross/blackfriday"
)

So as you see there is a problem here…

2 Likes
8

Are you talking about https://github.com/hayajo/md2pdf?

That hasn’t been touched for 4 years, I expect a lot of incompatibilities.

If you are talking about something else you’ll need to elaborate.

2 Likes
9

no, about this https://github.com/mandolyte/mdtopdf
This hasn’t been touched for about one year, but it seems there are some incompatibilities also.

2 Likes
10

Yeah, they are importing from gopkg.in. this can’t work from a go modules context.

Either fork that project and fix the imports or search for another converter that actually is compatible with modules.

3 Likes
11

could you please describe it more in detail,
after it will be forked where should I fix imports and what to fix?

2 Likes
12

Well, you fork the mdtopdf project and change all imports of blackfriday to its GitHub equivalent, while also changing all internal imports to your fork.

3 Likes
13

great

2 Likes
14

the last question, why importing from gopkg.in doesn’t work for a go modules context?

2 Likes
15

It probably would, if the package provided didn’t have a go.mod file contradicting the import path.

2 Likes
16

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.