Closed abourget closed 12 months ago
@abourget What about run/gui
? Were you expecting people to perform a .pack
to use the override feature? I discussed with Colin this morning and it was weird to me to force developers to have a pack
.
Would it make sense to rework it so we have a different kind of manifest, we'd pick up on the difference using something like package.override: path/to/module
? And in that case, we'd laod the overridden module. This would allow us to always have a single file to point to.
It makes a lot of sense because an override always needs to know what it is overriding. It doesn't make sense that it doesn't know, and leave it to the command-line runner!
@maoueh @colindickson
Add a deriveFrom
field in the Manifest...
specVersion: v0.1.0
deriveFrom: https://github.com/streaming/substreams-core/v1/file.spkg
package:
name: "substreams-polygon"
version: v0.4.3
network: polygon
initialBlocks:
mod2: 123123123
params:
mod1: "123123"
You can override certain field
So we remove the -c
in pack or any other flags
Validation:
package.name
OPTIONAL
package.version
OPTIONAL
network
: OPTIONAL
initialBlocks
: OPTIONAL
params
: OPTIONAL
Support a separate file like
substreams.polygon.yaml
that ends with:and can be packed as an additional
spkg
with:Try to find the algorithm to resolve the
initalBlocks
just like the Manifest algorithm does, but when we're given anspkg
and asked to overrideinitialBlocks
.!! We also want to be able to override the
sink_config
andsink_module
.initialBlock
resolution algorithm (that checks for dependencies).. Perhaps merge the file before doing the descent. See https://github.com/streamingfast/substreams/issues/207 for a block mapping proposition on the command-line, to stay consistent.