-
Notifications
You must be signed in to change notification settings - Fork 525
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
Export main function #646
base: master
Are you sure you want to change the base?
Export main function #646
Conversation
- allows creating custom goose binary without replicating CLI logic
Main() | ||
} | ||
|
||
func Main() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is typically not exported, and I'm not sure I want to allow a dependency on the CLI code. Note, there will be some changes to this coming very soon: #663
I'm curious, what are you trying to do where the goose package isn't sufficient?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hello there!
We want to embed go migrations in the goose binary.
Currently, this is done by implementing a custom CLI interface alongside the migrations, which is a bit annoying.
The laziest way to do it was to simply export the main function, so that is what I did. There are probably better ways to achieve this. The issue you linked looks promising :)
It would be really nice with a GooseCLI function or something that accepted configuration as input.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, okay I think I understand. You want to use Go migrations but also leverage the default CLI behaviour from goose without re-implementing flags/args logic within your binary code.
I'll need to think about this. The goose.Run
set of commands were meant to bridge this gap, although there's still all the configuration, flags and env bits you need to glue together.
Need to think about this, because anything that becomes part of the public API surface we try very hard to keep backwards-compatible. Most CLIs keep this in ./internal/cli
since it's only ever used as an executable, but this is a bit of a special case because of the intersection of Go migrations + CLI functionality.
Okay, I've come around on this. I think there's some benefit to making the CLI bits available to users. I don't want to expose func Main() {
}
# and
func Run(ctx context.Context, args []string, opts ...RunOptions) error {
} Which will enable you to call |
allows creating custom goose binary without replicating CLI logic