Base directory is hardcoded for init script
Opened this issue · 13 comments
I'm writing an adapter around Migratus for an internal task runner. I'd like to write tests for it, and I'd like those tests to use a suite of migrations in my project's test_resources
directory. I see there is a :parent-migration-dir
option which controls where Migratus looks for the migrations
directory, and this project's own tests use that option to run test migrations. The init
function, however, does not respect this setting; it always looks in resources
.
Ah yeah, that looks like an omission. Any chance you could do a PR for this?
Unfortunately my company's OSS policies are...unsettled, and I can't at present make contributions.
Ah, fair enough. I'll take a look.
Hmm, it looks like the init-script
should already be resolved relative to the migration directory
migratus/src/migratus/database.clj
Line 123 in f0972c6
When that function is called, the directory provided does not account for this option. It resolves the :migration-dir
option against a base path, but the base path is static.
Tracing the data flow:
We dispatch init
on store type, which is generally going to be :database
.
migratus/src/migratus/core.clj
Lines 191 to 194 in f0972c6
The database implementation of init
passes its entire config to get-migration-dir
and get-init-script
.
migratus/src/migratus/database.clj
Lines 292 to 300 in f0972c6
Both of those functions look only at their respective properties, falling back to the defaults of "migrations"
and "init.sql"
.
migratus/src/migratus/utils.clj
Lines 20 to 28 in f0972c6
The init-db!
function passes those two values directly to find-init-script
and slurps the result.
migratus/src/migratus/database.clj
Lines 279 to 282 in f0972c6
Nothing along the way has accounted for :parent-migration-dir
, and at this point in the call stack we no longer have access to that value because we're no longer holding the entire config.
Here is where the actual hardcoding happens:
migratus/src/migratus/utils.clj
Lines 80 to 89 in f0972c6
And the function we've used to find the script does indeed call that unary overload of find-migration-dir
:
migratus/src/migratus/database.clj
Lines 123 to 128 in f0972c6
Ah ok, thanks for digging in. It's been a while since I've looked at it. I'll try get a fix out in the coming days.
Also worth mentioning: This option isn't actually documented. One alternative is to just say it's an implementation detail and not make this change. I think my use case is a compelling one for promoting it to a full-fledged feature, though.
Yeah, I think this would be worth doing and doesn't look like it should be too much work.
Ah, I just discovered that this also happens with the migrate
function. Same basic flow – it lands in that unary overload of find-migration-dir
. Full support for this option might wind up touching a fair amount of the public API.
Ah yeah, looks like it might be a bit more fiddly than it initially appeared. Perhaps for your use case it might be easier to just use with-redefs
for find-init-script
.
I wound up settling on a workaround of just using a couple ..
segments in the configuration. Not ideal, but adequate!
I'll keep the issue open. I think it'd be good to fix if I get time. Glad the workaround is working in the mean time.