-
Notifications
You must be signed in to change notification settings - Fork 18k
cmd/go: go build support for importing/linking additional packages #14088
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
What's wrong with putting the side effect import
statement into a source file?
Note that you can easily switch between sql database
drivers by having multiple files each with a different
build tag and import a different sql driver package.
|
This assumes that the myapp author has either included all possible database/sql drivers, or that it provides a file for each database/sql driver with its own tag. Even just with SQL drivers (https://github.com/golang/go/wiki/SQLDrivers lists more than 20) this becomes hard quickly: imagine what could happen with application modules or plugins. Moreover, if the myapp maintainer doesn't want to import a specific package, you need to patch manually every time you build/run. Sure, the current state is not unbearable... it just feels like an unneeded hop to jump through. |
Allowing -import at go build/install time will not solve the problem either.
Consider:
go install pkg -import xxx/sql-driver -import yyy/plugin1 -import
zzz/plugin2
as compared to adding (and checking into SCM) a new file to pkg with the
content:
package pkg
import (
_ "xxx/sql-driver"
_ "yyy/plugin1"
_ "zzz/plugin2"
)
The proposed the solution might be convenient but will quickly grow into
maintenance problems (you can no longer reproduce the exact build
because you don't know the options used to build it and the command
is not checked into the repo.) Even build tags use should be minimized
for the same reason.
|
The fact that the use of something should be minimized doesn't imply that that something is not useful if used properly. I'm not advocating abuse of the feature I'm proposing; I'm advocating that it would be useful in certain limited scenarios - similarly to build tags, the -X flag to |
This request is missing a key detail: when would the package initializers for the extra packages run? (Before the initializers for the packages imported from At the moment, we have the nice property that package initializers run in a strict topological order. |
Note that you can structure something more-or-less as @minux suggests using modules and
package main
import _ "example.com/inject"
[…]
package inject
import _ "github.com/go-sql-driver/mysql"
package inject
import _ "my.localhost/sql-driver" |
Timed out in state WaitingForInfo. Closing. (I am just a bot, though. Please speak up if this is a mistake or you have the requested information.) |
I would love to be able to specify during go build/run additional packages to be imported. This would be mostly useful for those packages that are imported for their side effects.
As an example consider:
This should have the same effect as adding the following import in the root package of myapp:
Right now I'm using a quick-and-dirty tool for this but I really can't help thinking this should be part of the go command.
This would basically enable a very rudimental form of (compiler-mediated) DI.
The text was updated successfully, but these errors were encountered: