Then you add a step for adding the content hash as an environment variable in the installation instructions, and include the actual content hash as an _example_ (wink wink) in the documentation.
I don't think Bundler/Bundler-like project lockfiles work that way; lockfiles generally need to be static artifacts checked into source control, so that their transitive dependencies can be resolved and the whole tree of dependencies can be inter-constrained. Swapping the dep out for a different one would require you to re-lock everything.
And, even taking one step back and not having a lockfile, and instead using the dependency version-constraints spec file (the Gemfile) — constraint specs are still generally not really dynamic formats. "Runtime", for them, is compile-time; and usually you can't execute code in them, because the runtime needs to load and resolve them before any of your library's code gets to run. If your app depends on the Rails gem, Rails doesn't get any opportunity during dependency-resolution to run code that decides what its transitive dependencies will be.
(One exception to this general rule in package ecosystems, is Python, due to the existence of setup.py files. This exception is why `pipenv install` in a large Python project takes upwards of 15 minutes: nothing can be parallelized — or ever truly locked down to a specific version — because each dependency gets to run arbitrary, not-guaranteed-deterministic code during installation to decide what its own transitive dependencies will be.)
You could probably create some sort of shim library that dynamically downloads your actual library at runtime — first rewriting its transitive deps, and then loading it as a dep through low-level use of the runtime packaging machinery... but at that point it's a lot easier to just actually load the database itself by dynamic reference.
And, even taking one step back and not having a lockfile, and instead using the dependency version-constraints spec file (the Gemfile) — constraint specs are still generally not really dynamic formats. "Runtime", for them, is compile-time; and usually you can't execute code in them, because the runtime needs to load and resolve them before any of your library's code gets to run. If your app depends on the Rails gem, Rails doesn't get any opportunity during dependency-resolution to run code that decides what its transitive dependencies will be.
(One exception to this general rule in package ecosystems, is Python, due to the existence of setup.py files. This exception is why `pipenv install` in a large Python project takes upwards of 15 minutes: nothing can be parallelized — or ever truly locked down to a specific version — because each dependency gets to run arbitrary, not-guaranteed-deterministic code during installation to decide what its own transitive dependencies will be.)
You could probably create some sort of shim library that dynamically downloads your actual library at runtime — first rewriting its transitive deps, and then loading it as a dep through low-level use of the runtime packaging machinery... but at that point it's a lot easier to just actually load the database itself by dynamic reference.