Installation error

[mauri870]

When trying to install this package in a go modules enabled project(golang:latest image) I got the following error:

go: extracting github.com/tensorflow/tensorflow v1.13.1
# github.com/owulveryck/onnx-go/internal/pb-onnx
/go/pkg/mod/github.com/owulveryck/onnx-go@v0.0.0-20190603203622-587bc393a7ed/internal/pb-onnx/onnx.proto3.pb.go:22:11: undefined: proto.ProtoPackageIsVersion3
# gorgonia.org/gorgonia
/go/pkg/mod/gorgonia.org/gorgonia@v0.9.1/graph.go:569:2: cannot use e (type edge) as type graph.Edge in return argument:
        edge does not implement graph.Edge (missing ReversedEdge method)
/go/pkg/mod/gorgonia.org/gorgonia@v0.9.1/node.go:437:16: n.shape.CalcStrides undefined (type tensor.Shape has no field or method CalcStrides)
/go/pkg/mod/gorgonia.org/gorgonia@v0.9.1/node.go:756:15: cannot use e (type edge) as type graph.Edge in argument to n.g.SetEdge:
        edge does not implement graph.Edge (missing ReversedEdge method)
/go/pkg/mod/gorgonia.org/gorgonia@v0.9.1/utils.go:147:28: undefined: tensor.InfChecker
/go/pkg/mod/gorgonia.org/gorgonia@v0.9.1/utils.go:190:28: undefined: tensor.NaNChecker

[blackrez]

Hello,

Can you provides the go.mod and eventually the Dockerfile to be able to reproduce the error ?

Thanks in advance.

[mauri870]

I reproduced this without a go.mod, so the instructions are:

• Create a project that uses this package with the gorgonia backend
• go mod init myproject.org/package
• go build

You should see similar results

[mauri870]

• Create an empty dir, then write a main.go:

package main

import (
        "fmt"
        "github.com/owulveryck/onnx-go/backend/x/gorgonnx"
)

func main() {
        backend := gorgonnx.NewGraph()
}

• go mod init myproject.org/package
• go build

[blackrez]

Ok, I could reproduce the bug. I will investigate.

[mauri870]

Thank you. Maybe adding a go.{mod,sum} to your package and locking the package versions that it depends can prevent this from happening in the future.

[owulveryck]

Maybe adding a go.{mod,sum} to your package and locking the package versions that it depends can prevent this from happening in the future.

TL;DR: good idea, but this may be too early.

Longer: By now we (try to) make onnx-go compatible with the master branches of the dependencies (this is what the CI checks uppon a push on the repo).
This guarantees that the package is go-gettable, which is essential because it is a library and not a utility.

The project is in active development, and some features require to add/patch things in the significant dependencies such as Gorgonia and Tensor lib (take the very recent example of the Leaky-Relu Operator for instance). Therefore it's hard, by now, to lock a package version because Gorgonia does not release a version on each patch.

WDYT?

Oh, and one more thing: I've seen this good talk from @jadekler, and I must say that it has scared me enough to stay away from the go modules, for now, and keep the focus on the features and performances of the library.

[mauri870]

LGTM

I'll stay away from go modules for now then. The main reason I would like to use this library with go mod is to get rid of the tensorflow shared object dependency in production. Anyway, thanks for your help :)

[owulveryck]

The main reason I would like to use this library with go mod is to get rid of the tensorflow shared object dependency in production.

I don't get your point? This repo is independent of Tensorflow, and if you compile a binary, you can bring it to production without carrying about dependencies at runtime. Tell me if I missed something?

Anyway, thanks for your help :)

Thank you @blackrez for the investigation, you rock! I let you close the issue whenever you want if you think that this is not fixable by now (or keep it open if you plan to fix it ;)).

[jeanbza]

Hello!

Oh, and one more thing: I've seen this good talk from @jadekler, and I must say that it has scared me enough to stay away from the go modules, for now, and keep the focus on the features and performances of the library.

I'll stay away from go modules for now then. The main reason I would like to use this library with go mod is to get rid of the tensorflow shared object dependency in production. Anyway, thanks for your help :)

Note that although multi-module repositories (the topic of the video, and an "advanced" setup) is tricky, single-module repositories (the normal, mainstream case) should be quite straightforward and easy to maintain.

Essentially, all that needs to be done is:

go mod init
go mod tidy

And then during every PR, you use go mod tidy to ensure you're capturing any newly-added dependencies. (CI can check for it like so: spf13/viper#706).

Happy to provide additional guidance if you'd like to discuss any part of adopting Go modules! :)

[blackrez]

I was looking for a solution (thanks @jadekler for pointing this idea). I will close this issue and create a new issue on support go modules.