TL;DR
Go Moduleのreplace機能とGit Submoduleを使う
経緯
cgoなどの依存があり、Makefileを実行する必要があったりしてgo getでインストールするとうまく動かないライブラリはGo Moduleでそのまま扱えないことがあります。
対策
私が躓いたライブラリは github.com/zubairhamed/canopus でした。このライブラリは内部でOpenSSLを利用しており./configとmakeを実行する必要がありました。go getで入れようとするとopensslのヘッダファイルがないと言われてインストールできません。
go.modには当初
require (
...
github.com/zubairhamed/canopus v0.0.0-201XXXXXXXXXXX-abcdefghijkl
)
このようになっていました。(ちゃんとバージョニングされて入ればv1.0.0のようになります)
これに
replace github.com/zubairhamed/canopus => ./canopus
replaceをこのように加えてディレクトリのパスを指定します。こうするとgithub.com/zubairhamed/canopus以下のライブラリを利用しようとすると./canopusのディレクトリを利用するようになります。
あとは./canopus以下にライブラリをインストールします。
ですがそのまま管理するのは微妙なためsubmoduleで管理するのが良いと思います。
git submodule add https://github.com/zubairhamed/canopus.git
以上で完了です。
これ以降、このパッケージをビルドする際にはgit clone後、git submodule update --init --recursiveをし、(Makefile等を用いて)submoduleのディレクトリ内でのインストール処理を済ませた後、go buildをすればOKです。
ただし、もしこのパッケージ自体がライブラリであった場合、他のライブラリから利用する場合も同じようなことをする必要が出てきます。
注意
もしreplaceしたライブラリがGo Moduleを非使用でgo.modがない場合ビルドに失敗します。応急処置としてはtouch ./canopus/go.modをすればビルドはできます。が、あまり綺麗ではないのでもっと良いやり方があれば教えていただきたいです。
まとめ
Go ModuleはPure Goのライブラリ等だと扱いやすいですが扱えないライブラリはGo Moduleから切り離しGitで管理するのが現状楽そうです。
まだGo Moduleは導入されて日が浅く浸透しているとまでは言えませんが今後更に知見が共有されていくと嬉しいです。