ysim / cook

command-line recipe management
MIT License
8 stars 0 forks source link

Problem compiling from source (due to blackfriday versioning?) #53

Open fe5hua opened 2 years ago

fe5hua commented 2 years ago

Hi, sorry if I did a stupid mistake compilling cook. I am quite new to go. I am trying to compile cook from source, because I am on OpenBSD (amd64) and there are not precompiled binarys. When following the instructions get an error compiling with the notice to go mod init. This results in a different error with notice go mod vendor. And finally I get an error undefined: blackfriday.Run which (after some digging) seems to be a result of using blackfriday v1.x with syntax from v2.

Here is my whole process:

user@hostname in ~/go/src
→ $ git clone https://github.com/ysim/cook.git 
Cloning into 'cook'...
remote: Enumerating objects: 751, done.
remote: Total 751 (delta 0), reused 0 (delta 0), pack-reused 751
Receiving objects: 100% (751/751), 106.07 KiB | 88.00 KiB/s, done.
Resolving deltas: 100% (440/440), done.
user@hostname in ~/go/src
→ $ cd cook/
user@hostname in ~/go/src/cook
! $ dep ensure                                 
user@hostname in ~/go/src/cook
→ $ make build GOOS=openbsd GOARCH=amd64       
go build -ldflags "-X main.version=v0.3.0" -o cook 
go: cannot find main module, but found Gopkg.lock in ~/go/src/cook
    to create a module there, run:
    go mod init
*** Error 1 in ~/go/src/cook (Makefile:8 'build')
user@hostname in ~/go/src/cook
! $ go mod init
go: creating new go.mod: module cook
go: converting Gopkg.lock: stat github.com/russross/blackfriday@v2.0.1: github.com/russross/blackfriday@v2.0.1: invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v2
go: copying requirements from Gopkg.lock
go: to add module requirements and sums:
    go mod tidy
user@hostname in ~/go/src/cook
→ $ make build GOOS=openbsd GOARCH=amd64 
go build -ldflags "-X main.version=v0.3.0" -o cook 
go: inconsistent vendoring in ~/go/src/cook:
    github.com/davecgh/go-spew@v1.1.1: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt
    github.com/konsorten/go-windows-terminal-sequences@v1.0.2: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt
    github.com/pmezard/go-difflib@v1.0.0: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt
    github.com/shurcooL/sanitized_anchor_name@v1.0.0: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt
    github.com/sirupsen/logrus@v1.6.0: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt
    github.com/stretchr/testify@v1.6.1: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt
    golang.org/x/net@v0.0.0-20190628185345-da137c7871d7: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt
    golang.org/x/sys@v0.0.0-20190712062909-fae7ac547cb7: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt
    gopkg.in/yaml.v3@v3.0.0-20200615113413-eeeca48fe776: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt

    To ignore the vendor directory, use -mod=readonly or -mod=mod.
    To sync the vendor directory, run:
        go mod vendor
*** Error 1 in ~/go/src/cook (Makefile:8 'build')
user@hostname in ~/go/src/cook
! $ go mod vendor                              
go: finding module for package github.com/russross/blackfriday
go: found github.com/russross/blackfriday in github.com/russross/blackfriday v1.6.0
user@hostname in ~/go/src/cook
→ $ make build GOOS=openbsd GOARCH=amd64 
go build -ldflags "-X main.version=v0.3.0" -o cook 
# cook
./parser.go:106:15: undefined: blackfriday.Run
*** Error 2 in ~/go/src/cook (Makefile:8 'build')

Thanks

ysim commented 2 years ago

And finally I get an error undefined: blackfriday.Run which (after some digging) seems to be a result of using blackfriday v1.x with syntax from v2.

Yes, you're exactly right, I ran into this issue when I was making a release to migrate from dep to go modules.

The latest master should have the update with the fix in. Thank you for opening this issue!