Check-only mode for rewriting migrations.toml

[antifuchs]

I'm trying to build a rust crate using nix's crane library, which breaks the build into two parts:

1. It builds all the dependencies with a "stub" crate in one temporary build dir,
2. packages up the target/ directory,
3. builds the "main" crate with the previous target/ directory in place, in a second temporary build dir

This usually works great, but with turbosql, there is an issue: In the third step, it attempts to write to the migrations.toml into the build dir from the first step.

I'm not sure why it picks the wrong build dir, but I feel like this is not ideal in any case: For these builds, I'd love to be able to turn off turbosql re-writing the migrations.toml file, in favor of checking that it's the same as the one that it would be writing - somewhat like the "locked" mode in yarn or cargo.

Does that make sense?

[trevyn]

Thanks for the report! It sounds like there's two separate things here:

1. An issue with building with nix/crane.
2. A request for a locked mode.

I'll take a look at the nix/crane issue, though I have no experience with nix, so any repro advice is welcome! I will note that it sounds like some of the macro invocations are having trouble finding the correct migrations.toml, which would cause a problem even before rewriting becomes a question -- I do not believe that the simple presence of a locked mode would solve this issue.

Even when the build issue is resolved, I get the impression that you desire a locked mode regardless, yes? Would an env var trigger be appropriate? (I'm imagining in CI, for example.)

[antifuchs]

Even when the build issue is resolved, I get the impression that you desire a locked mode regardless, yes? Would an env var trigger be appropriate? (I'm imagining in CI, for example.)

Yes! I think that is going to be much more bang for the buck here. Your assumption is exactly right: The issue is about running in CI (crane just optimizes things for shorter CI run-times). In CI, I think we just can never guarantee that the source tree is going to be writeable (or commitable), when all we need is an indicator that not all migrations have properly been checked in (:

[antifuchs]

Oh, I forgot the second part of the question: An environment variable would make a lot sense. I don't think there's a global "initialize this" call/macro that could be told not to action any migrations.toml rewrites, right? If there was, I would probably structure this as some attribute that could be used with #[cfg_attr()].