Issue #11: Handling of modules in dependencies - go2rpm

GoSIG / go2rpm

#11 Handling of modules in dependencies

Closed 23 days ago by gotmax23. Opened 3 years ago by zakkak.

Hello,

go2rpm github.com/twpayne/chezmoi

fails with:

ERROR: Unable to 'go get github.com/twpayne/chezmoi':
package github.com/google/go-github/v26/github: cannot find package "github.com/google/go-github/v26/github" in any of:
        /usr/lib/golang/src/github.com/google/go-github/v26/github (from $GOROOT)
        /home/fzakkak/.cache/go2rpm/src/github.com/google/go-github/v26/github (from $GOPATH)

Which is caused because the go import path github.com/google/go-github/v26/github requires modules to be enabled, but they are explicitly disabled in go2rpm.

As of Go 1.14, developers are encouraged to start using modules (see https://github.com/golang/go/wiki/Modules), as a result I believe go2rpm should also start supporting them.

What are your thoughts?

ngompa commented 3 years ago

I'm pretty sure @nim has been looking at making the switch to supporting Go Modules natively.

nim commented 3 years ago

While I have, indeed, been working on module support (just yesterday as it happens) current Fedora packaging tools do permit packaging any import path, be it module or non-module style There are much weirder import paths constructs out there, than the convention modules created.

Just play on the difference between the project root URL (%{forgeurl}) and the module/import path name (%{goipath}). And use the multi-import-path capabilities of the macros to handle submodules.

However, any special case requires using the packaging templates in go-rpm-templates (what FPC approved), not an helper like go2rpm, that, by nature, only handles the simple common case.

In fact there are several Go packages in the distro that will eventually need redoing, because they were done blindly with go2rpm, and the packager was not aware enough of guidelines and Fedora templates, to tweak go2rpm output when adjustment was needed.

Because modules do break officially the link between project URL and Go module names¹, the difference between them will be emphasized in the next module-aware template set.

¹ The official upstream recommendation is to materialize versions as real not faked directories, but projects do not bother.

Edited 3 years ago by nim