I got half-way through a reply to your original message and then got distracted, sorry. Looks like you’ve worked something out. For reference, here is what I was going to say:
The short answer is no, you can’t have one
DependencyProvider depend on another. That’s because the dependency injection step is specifically about injecting the result of
get_dependency into a service worker. The injection mechanism only works from DP to service, not DP to DP.
DependencyProvider can have nested
SharedExtensions though. A good example of this is the
@http) entrypoint, which has a
SharedExtension. In this arrangement there’s a single webserver listening on the port, handling requests for all the
I think I would use straight-up inheritance to solve your problem though. Is there a problem with using one
DependencyProvider to establishes connections to Cassandra, and another that subclasses it to run the initialisation and provides the function to the service?
I don’t have enough information to comment on your particular use-case, but I generally discourage coupling extensions by name. It is often a sign of either overzealous code re-use, or poor separation of concerns.
By way of example, imagine a service that stores metrics and application data on the same physical database. It’s common to want to reuse the
DependencyProvider from one for the other, whereas IMO it’d be better to use two explicitly separate extensions even if that involved some code duplication.