[GH-ISSUE #190] events/impl.go references missing package, breaking go mod tidy #121

Closed
opened 2026-02-28 14:25:34 +03:00 by kerem · 8 comments
Owner

Originally created by @SaeidRp on GitHub (Aug 6, 2025).
Original GitHub issue: https://github.com/devgianlu/go-librespot/issues/190

Hey,
events/impl.go tries to import github.com/devgianlu/go-librespot/events/impl but this package doesn't exist in the codebase. This breaks go mod tidy when using the library as a dependency.
As a workaround, I simply removed impl.go, since we have dummy.go, which implements the Plugin interface.

Error:

go: finding module for package github.com/devgianlu/go-librespot/events/impl
go: github.com/devgianlu/go-librespot/events imports
        github.com/devgianlu/go-librespot/events/impl: no matching versions for query "latest"
Originally created by @SaeidRp on GitHub (Aug 6, 2025). Original GitHub issue: https://github.com/devgianlu/go-librespot/issues/190 Hey, `events/impl.go` tries to import `github.com/devgianlu/go-librespot/events/impl` but this package doesn't exist in the codebase. This breaks `go mod tidy` when using the library as a dependency. As a workaround, I simply removed `impl.go`, since we have `dummy.go`, which implements the `Plugin` interface. ## **Error:** ``` go: finding module for package github.com/devgianlu/go-librespot/events/impl go: github.com/devgianlu/go-librespot/events imports github.com/devgianlu/go-librespot/events/impl: no matching versions for query "latest" ```
kerem closed this issue 2026-02-28 14:25:34 +03:00
Author
Owner

@devgianlu commented on GitHub (Aug 6, 2025):

Ah, yes because go mod tidy ignores build tags. Not sure how this could be made portable without deleting impl.go.

<!-- gh-comment-id:3161140654 --> @devgianlu commented on GitHub (Aug 6, 2025): Ah, yes because `go mod tidy` ignores build tags. Not sure how this could be made portable without deleting `impl.go`.
Author
Owner

@SaeidRp commented on GitHub (Aug 6, 2025):

We can fix this by using a registration pattern instead of direct imports:

New impl.go:

//go:build events

package events

import (
	"github.com/devgianlu/go-librespot/events/plugin"
)

// Plugin uses dummy implementation by default
// Local impl/ package can override this via init() if present
var Plugin plugin.Interface = dummyPlugin{}

Your local impl/impl.go would then do:

//go:build events

package impl

import (
	"github.com/devgianlu/go-librespot/events"
)

func init() {
	events.Plugin = Impl{} // Override the default
}

type Impl struct{}
// ... your implementation

Would you be okay with this approach? If so, I can open a PR.

<!-- gh-comment-id:3161178952 --> @SaeidRp commented on GitHub (Aug 6, 2025): We can fix this by using a registration pattern instead of direct imports: **New `impl.go`:** ```go //go:build events package events import ( "github.com/devgianlu/go-librespot/events/plugin" ) // Plugin uses dummy implementation by default // Local impl/ package can override this via init() if present var Plugin plugin.Interface = dummyPlugin{} ``` **Your local `impl/impl.go` would then do:** ```go //go:build events package impl import ( "github.com/devgianlu/go-librespot/events" ) func init() { events.Plugin = Impl{} // Override the default } type Impl struct{} // ... your implementation ``` --- Would you be okay with this approach? If so, I can open a PR.
Author
Owner

@devgianlu commented on GitHub (Aug 6, 2025):

Yes, that might work! Feel free to open a PR.

<!-- gh-comment-id:3161193998 --> @devgianlu commented on GitHub (Aug 6, 2025): Yes, that might work! Feel free to open a PR.
Author
Owner

@SaeidRp commented on GitHub (Aug 7, 2025):

I don’t think this approach will work as I previously thought. I’m curious how is the impl/directory actually being added? If we’re relying on the files within the impl/ directory, maybe we could include a placeholder/dummy Impl struct there. Then, if users want to provide their own implementation, they can simply overwrite this file or directory. Does that make sense?

<!-- gh-comment-id:3163304719 --> @SaeidRp commented on GitHub (Aug 7, 2025): I don’t think this approach will work as I previously thought. I’m curious how is the `impl/`directory actually being added? If we’re relying on the files within the `impl/` directory, maybe we could include a placeholder/dummy `Impl struct` there. Then, if users want to provide their own implementation, they can simply overwrite this file or directory. Does that make sense?
Author
Owner

@devgianlu commented on GitHub (Aug 7, 2025):

I've tried your solution and it seems to work:

diff --git a/events/dummy.go b/events/dummy.go
--- a/events/dummy.go
+++ b/events/dummy.go
@@ -1,11 +1,8 @@
-//go:build !events
-
 package events
 
 import (
        librespot "github.com/devgianlu/go-librespot"
        "github.com/devgianlu/go-librespot/audio"
-       "github.com/devgianlu/go-librespot/events/plugin"
        "github.com/devgianlu/go-librespot/mercury"
        "github.com/devgianlu/go-librespot/player"
        connectpb "github.com/devgianlu/go-librespot/proto/spotify/connectstate"
@@ -13,8 +10,6 @@ import (
        "github.com/devgianlu/go-librespot/spclient"
 )
 
-var Plugin plugin.Interface = dummyPlugin{}
-
 type dummyPlugin struct {
 }
 
diff --git a/events/impl.go b/events/impl.go
--- a/events/impl.go
+++ b/events/impl.go
@@ -1,10 +1,5 @@
-//go:build events
-
 package events
 
-import (
-       "github.com/devgianlu/go-librespot/events/impl"
-       "github.com/devgianlu/go-librespot/events/plugin"
-)
+import "github.com/devgianlu/go-librespot/events/plugin"
 
-var Plugin plugin.Interface = impl.Impl{}
+var Plugin plugin.Interface = dummyPlugin{}

Then, inside the implementation:

diff --git a/plugin.go b/plugin.go
--- a/plugin.go
+++ b/plugin.go
@@ -1,4 +1,12 @@
 package impl
 
+import (
+       "github.com/devgianlu/go-librespot/events"
+)
+
 type Impl struct {
 }
+
+func init() {
+       events.Plugin = Impl{}
+}
<!-- gh-comment-id:3163427284 --> @devgianlu commented on GitHub (Aug 7, 2025): I've tried your solution and it seems to work: ```diff diff --git a/events/dummy.go b/events/dummy.go --- a/events/dummy.go +++ b/events/dummy.go @@ -1,11 +1,8 @@ -//go:build !events - package events import ( librespot "github.com/devgianlu/go-librespot" "github.com/devgianlu/go-librespot/audio" - "github.com/devgianlu/go-librespot/events/plugin" "github.com/devgianlu/go-librespot/mercury" "github.com/devgianlu/go-librespot/player" connectpb "github.com/devgianlu/go-librespot/proto/spotify/connectstate" @@ -13,8 +10,6 @@ import ( "github.com/devgianlu/go-librespot/spclient" ) -var Plugin plugin.Interface = dummyPlugin{} - type dummyPlugin struct { } diff --git a/events/impl.go b/events/impl.go --- a/events/impl.go +++ b/events/impl.go @@ -1,10 +1,5 @@ -//go:build events - package events -import ( - "github.com/devgianlu/go-librespot/events/impl" - "github.com/devgianlu/go-librespot/events/plugin" -) +import "github.com/devgianlu/go-librespot/events/plugin" -var Plugin plugin.Interface = impl.Impl{} +var Plugin plugin.Interface = dummyPlugin{} ``` Then, inside the implementation: ```diff diff --git a/plugin.go b/plugin.go --- a/plugin.go +++ b/plugin.go @@ -1,4 +1,12 @@ package impl +import ( + "github.com/devgianlu/go-librespot/events" +) + type Impl struct { } + +func init() { + events.Plugin = Impl{} +} ```
Author
Owner

@SaeidRp commented on GitHub (Aug 7, 2025):

I think that since the impl package isn’t imported anywhere, its init() function will never be called. As a result, the Plugin won’t actually get registered

<!-- gh-comment-id:3163504684 --> @SaeidRp commented on GitHub (Aug 7, 2025): I think that since the `impl` package isn’t imported anywhere, its `init()` function will never be called. As a result, the Plugin won’t actually get registered
Author
Owner

@SaeidRp commented on GitHub (Sep 13, 2025):

I ended up adding an events/impl/impl.go placeholder so that when a plugin is present, it can just overwrite this file. That way, we avoid missing reference issues and everything still compiles cleanly.

You can check the changes here:
https://github.com/devgianlu/go-librespot/compare/master...SaeidRp:go-librespot:master

If this approach works for you, let me know and I’ll open a PR.

<!-- gh-comment-id:3287984442 --> @SaeidRp commented on GitHub (Sep 13, 2025): I ended up adding an `events/impl/impl.go` placeholder so that when a plugin is present, it can just overwrite this file. That way, we avoid missing reference issues and everything still compiles cleanly. You can check the changes here: https://github.com/devgianlu/go-librespot/compare/master...SaeidRp:go-librespot:master If this approach works for you, let me know and I’ll open a PR.
Author
Owner

@devgianlu commented on GitHub (Oct 15, 2025):

Yes, that's probably the best idea. I'd move the dummy implementation into the impl folder so that everything works smooth.

<!-- gh-comment-id:3405744557 --> @devgianlu commented on GitHub (Oct 15, 2025): Yes, that's probably the best idea. I'd move the dummy implementation into the `impl` folder so that everything works smooth.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/go-librespot#121
No description provided.