ebiten icon indicating copy to clipboard operation
ebiten copied to clipboard

fork gomobile and use it to avoid the dependency conflictions

Open tinne26 opened this issue 9 months ago • 7 comments

Ebitengine Version

>=v2.6.0

Go Version (go version)

go1.21.1

What steps will reproduce the problem?

Initialize a module, e.g.: go mod init shinydep

Create a trivial main.go file using any third-party package depending on Ebitengine <v2.6.0:

package main

import "github.com/hajimehoshi/ebiten/v2"
import "github.com/tinne26/etxt"
import "github.com/quasilyte/ebitengine-input"

var lib    = etxt.NewFontLibrary()
var action = input.Action(1)
var blend  = ebiten.Blend{}

func main() {}

(Showing both etxt and ebitengine-input because the two are affected, but any one of them in isolation is enough to reproduce)

Run go mod tidy to add module requirements and sums.

What is the expected result?

Successful go mod tidy execution.

What happens instead?

go: finding module for package github.com/tinne26/etxt
go: finding module for package github.com/hajimehoshi/ebiten/v2
go: finding module for package github.com/quasilyte/ebitengine-input
go: found github.com/hajimehoshi/ebiten/v2 in github.com/hajimehoshi/ebiten/v2 v2.6.1
go: found github.com/quasilyte/ebitengine-input in github.com/quasilyte/ebitengine-input v0.9.0
go: found github.com/tinne26/etxt in github.com/tinne26/etxt v0.0.8
go: shinydep imports
        github.com/hajimehoshi/ebiten/v2 imports
        github.com/hajimehoshi/ebiten/v2/internal/ui imports
        golang.org/x/mobile/app imports
        golang.org/x/exp/shiny/driver/gldriver: ambiguous import: found package golang.org/x/exp/shiny/driver/gldriver in multiple modules:
        golang.org/x/exp v0.0.0-20190731235908-ec7cb31e5a56 (C:\Users\username\go\pkg\mod\golang.org\x\[email protected]\shiny\driver\gldriver)
        golang.org/x/exp/shiny v0.0.0-20230817173708-d852ddb80c63 (C:\Users\username\go\pkg\mod\golang.org\x\exp\[email protected]\driver\gldriver)
go: shinydep imports
        github.com/hajimehoshi/ebiten/v2 imports
        github.com/hajimehoshi/ebiten/v2/internal/ui imports
        golang.org/x/mobile/app imports
        golang.org/x/exp/shiny/screen: ambiguous import: found package golang.org/x/exp/shiny/screen in multiple modules:
        golang.org/x/exp v0.0.0-20190731235908-ec7cb31e5a56 (C:\Users\username\go\pkg\mod\golang.org\x\[email protected]\shiny\screen)       
        golang.org/x/exp/shiny v0.0.0-20230817173708-d852ddb80c63 (C:\Users\username\go\pkg\mod\golang.org\x\exp\[email protected]\screen)

Anything else you feel useful to add?

This was already seen on https://github.com/hajimehoshi/ebiten/issues/2769, but I think the impact was underestimated; it affects many major libraries in the ecosystem.

Users are forced to run go get github.com/hajimehoshi/ebiten/v2 manually first in order to avoid the problem, as running go mod tidy directly will fail.

I don't know if this is considered a compatibility break or not, and I don't know if there's anything else that can be done (as I understand shiny is not stable and so there can be problems adapting to its changes), but this does have a non-trivial impact on third-party package users used to the go mod tidy workflow and basically forces third-party package developers to either raise the Ebitengine version to v2.6.0 for their packages or write additional notes on how to bypass the problem. And of course, beyond quasilyte/ebitengine-input and tinne26/etxt, this should also affect yohamta/donburi, ebitenui, SolarLune/resound and almost every package on sedyh/awesome-ebitengine that depends on Ebitengine.

To clarify, I mostly created this issue because I wanted to visibilize and document the problem and workarounds for affected users and package maintainers.

CC @SolarLune @quasilyte @yohamta @mcarpenter622

tinne26 avatar Oct 07 '23 15:10 tinne26