You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be great if local imports could be supported/enabled out of the box without having to make changes to any code. That would make it possible to include this repo as submodule. For certain use cases it may not be acceptable to pull files from github on build and having a local copy is required.
But assuming that there will be breaking changes with v2 anyway (?), now might be a good time to consider supporting this use case natively.
A possible solution would be to not include dependencies in the individual files, but instead have two entrypoints, say C4_all.puml and C4_all_local.puml that include all dependencies in the right order: One uses github imports and the other uses local imports. That way the user can choose which way to import. The downside of this approach is of course that all components would always be included, but I think that's an acceptable tradeoff. The user would always be able to customize which components to import by not relying on C4_all and importing the required files manually.
The text was updated successfully, but these errors were encountered:
@dstockhammer You are not alone in wanting to use local import... @kirchsth has implemented a RELATIVE_INCLUDE variable in #107 which makes it possible to use local version with an additional command line argument:
It would be great if local imports could be supported/enabled out of the box without having to make changes to any code. That would make it possible to include this repo as submodule. For certain use cases it may not be acceptable to pull files from github on build and having a local copy is required.
I've made that scenario work with a fork, see dstockhammer@d444d99
But assuming that there will be breaking changes with v2 anyway (?), now might be a good time to consider supporting this use case natively.
A possible solution would be to not include dependencies in the individual files, but instead have two entrypoints, say
C4_all.puml
andC4_all_local.puml
that include all dependencies in the right order: One uses github imports and the other uses local imports. That way the user can choose which way to import. The downside of this approach is of course that all components would always be included, but I think that's an acceptable tradeoff. The user would always be able to customize which components to import by not relying onC4_all
and importing the required files manually.The text was updated successfully, but these errors were encountered: