Illegal circular project dependency

Hey,

Looking for suggestions on how to best architecture our models, using remote_dependencies.

We want to be able -one day- to spin up several Looker instances, potentially in different infra perimeters or VPS, but while still retaining the ability to share models. So we decided to split our current model (one large file), into clearer domain-related projects with team/area specific models (for dev permissions management). One project in particular would be our analytics_base that all projects would import, but projects would still need for a few files here and there to import each others views.

So we started using the remote_dependencies on our 7.14 Looker instance, pointing to the projects in Github, and as we started rolling it out, we got the first signs that we had forgotten to consider one thing:

Several projects import each other, and create a circular dependency:

So, how do you go around that?

Any way to prevent the recursive imports and instead have it ignore or point to the local version?

Or is our only option to transfer those files into the main analytics_base, which is not ideal in terms of ownership and maintenance (we wanted it to be exclusive), and probably will result in people preferring to duplicate the views instead of importing?

1 2 518
2 REPLIES 2

@PedroMartin Have you heard anything further about this? I’m also running into a similar issue...

@PedroMartin Have you heard anything further about this? I’m also running into a similar issue...

Support has let us know this was by design and that no "trick" was available (at least 3 months ago, which was the last time I raised it).

So we ended up allowing some of our projects to import each other, and making sure their list of imports would not create a circular dependency. The rest of the projects have sadly had to keep on duplicating view and explore files.

Top Labels in this Space
Top Solution Authors