I think that we can get away with not forcing a checkout of vector-datasource. The config assets we need from there, which looks to be the queries yaml and jinja files currently, can just be bundled with the package itself. And when we need to read these on startup, we can simply expect it to be in a relative location from the vector-datasource package itself. Or we can just take a dotted name for the vector datasource package to support extensions.
This should simplify the installation instructions, our deployment automation, and some of our configuration.
IIRC the history here is that we didn't always have vector-datasource as a package, because there didn't used to be code there. But now that we do we shouldn't need to have to check it out separately.
I think that we can get away with not forcing a checkout of vector-datasource. The config assets we need from there, which looks to be the queries yaml and jinja files currently, can just be bundled with the package itself. And when we need to read these on startup, we can simply expect it to be in a relative location from the vector-datasource package itself. Or we can just take a dotted name for the vector datasource package to support extensions.
This should simplify the installation instructions, our deployment automation, and some of our configuration.
IIRC the history here is that we didn't always have vector-datasource as a package, because there didn't used to be code there. But now that we do we shouldn't need to have to check it out separately.