…s of the schema into the provided "schema_file" and made the migration commands raise appropriate Exceptions instead of just silently failing.
…ate"), the "base.path()" function raises an Exception.
…n message didn't make sense...
…to recognize the "requires" option, either. Otherwise, fairly successful distro.
…l this mess.
…nd parsing working correctly, I had to refactor most of the base module into functions. :/
…at "argparse" handles sub-commands, of course, but this is just easier for a first go.
…aging it for distutils. That broke all those symlinks, obviously.
…t to implement in Python, so I made a "migrate()" stored procedure in the "migrations" schema to handle that logic for me. This simplified my "apply" command significantly... And taught me a lot about PL/PgSQL. O_O
…renamed to "base" when refactoring to a package...
…I moved it into the "base" module as "with_schema_file()". Opening "create" made me notice an omission in the "MIGRATION_TEMPLATE": I didn't fully qualify the function definition...! Oops.
…lso made it more verbose, which turns out to be quite helpful when debugging.
…tributing this as a cheeseshop package.
… need to limit our "hash" field in "migrations"."history".
… add it, too. That also generates some migration files, which I wanted to ignore.
… same functionality as in "migration-init", so I refactored to make that available. I thought that I'd need the "get_HASH()" method from "migrations-create", as well, and moved that into the parent class, but turns out not so.
… breaking and all... And that helped in fixing the SQL. ;)
…ns.Command" base class for "migrations-init" as well.
…" class and helper functions.
…verride it elsewhere, if we have to, and the code isn't broken up by a giant string constant.
…g.sql" file that exists in version control and a "migrations" directory to put migrations in.
…create, init, and register. The "apply" command is just stubbed for the moment, "init" was the easiest (assuming pqsl is installed), and "create" is the most important immediately.