For example, every command requires you to specify the database / dsn and migrations directory:
goose -d sqlite:///my.db -m migrations/ init
I'm thinking the above would look a lot nicer if it used context and/or a configuration file to determine what to do and we could instead just write:
goose init
So we might consider a goose.conf in the current directory used to determine what commandline arguments to use or we might be able to use convention and say that if there is a migrations directory in the CWD that's what is used. Exactly what DSN is harder to handle through convention although I'm thinking that maybe init should write a configuration file that's used on subsequent invocations from that same directory.
So you'd do:
goose -d sqlite:///mysqlite.db init
-m migrations_dir would be figured out based on convention and a configuration file would be written to the current workind directory with the database DSN.
Future commands like would work without specifying either of these redundant arguments as long as those commands were run from the appropriate directory.
Alternatively goose could become a bit more knowledgeable about application configuration files and could read the appropriate DSN from settings.py (for django) or some other application config file.
For example, every command requires you to specify the database / dsn and migrations directory:
goose -d sqlite:///my.db -m migrations/ init
I'm thinking the above would look a lot nicer if it used context and/or a configuration file to determine what to do and we could instead just write:
goose init
So we might consider a goose.conf in the current directory used to determine what commandline arguments to use or we might be able to use convention and say that if there is a migrations directory in the CWD that's what is used. Exactly what DSN is harder to handle through convention although I'm thinking that maybe init should write a configuration file that's used on subsequent invocations from that same directory.
So you'd do:
goose -d sqlite:///mysqlite.db init
-m migrations_dir would be figured out based on convention and a configuration file would be written to the current workind directory with the database DSN.
Future commands like would work without specifying either of these redundant arguments as long as those commands were run from the appropriate directory.
Alternatively goose could become a bit more knowledgeable about application configuration files and could read the appropriate DSN from settings.py (for django) or some other application config file.