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
Is your feature request related to a problem? Please describe.
There's an extensive amount of interesting builders part of CIMTool, but you either have to run them from CIMTool or have some XSLT runner, in which case it's still not easy or even clear how to go about it.
Having the ability to release the builders standalone is beneficial because they can be used in CI/CD pipelines or quickly ran in the CLI by devs.
Furthermore, there might be benefit even in decoupling the builders as far as making them separate GitHub repos. This allows for independent versioning, making maintenance on CIMTool easier.
Describe the solution you'd like
Make the builders available in a standalone fashion, ideally with a small CLI interface or otherwise some API for easy programmatic calling.
Again, I think it's worth considering making them independent bits of software might be beneficial too.
Another approach is to have all builders be a new Github repository, so that a shared interface can be put on top of all of them (like LinkML does). If I were you (maintenance-wise) I would prefer one repo per builder, but that's totally your call :).
The text was updated successfully, but these errors were encountered:
I generally agree with the request. However, I do not see that have the current CIMTool builder support is preventing us for creating CI/CD standalone builder that can run on Github. We can then consider if we shall have a converter from new builder to the old builder. Maybe we are even able to have a bi-directional converter.
In general, I also agree to have a repo per builder - but I assume they are small and if they are maintained by the same group, it might be more efficient to have one for this group.
I generally agree with the request. However, I do not see that have the current CIMTool builder support is preventing us for creating CI/CD standalone builder that can run on Github. We can then consider if we shall have a converter from new builder to the old builder. Maybe we are even able to have a bi-directional converter.
I think it's meaningful to recognize the distinction between two things here:
Decoupling currently implemented builders in CIMTool and make them more easily available for standalone running (and optionally maintained in their own repos).
Creating new builders that are designed such that the can be used standalone and/or in CIMTool.
To be clear: this issue was intended to be (just) about (1). Your comments made me realize I had to zoom out a bit more, and touch on (2) as well.
If, moving forward, CIMTool will internally represent profiles in LinkML, I think new builders should be implemented such that they can:
operate directly on LinkML schemas as input (no other intermediate forms)
run standalone and without CIMTool as dependency
This way, the builders become LinkML generators (i.e. they take a LinkML schema and generate some artefact from it) that the entire community (but also CIMTool itself) can use.
So, new builders probably have a clear path, but what about the old builders? Is it worth the effort to come up with some (architectural?) change that makes it easier to use those standalone?
Is your feature request related to a problem? Please describe.
There's an extensive amount of interesting builders part of CIMTool, but you either have to run them from CIMTool or have some XSLT runner, in which case it's still not easy or even clear how to go about it.
Having the ability to release the builders standalone is beneficial because they can be used in CI/CD pipelines or quickly ran in the CLI by devs.
Furthermore, there might be benefit even in decoupling the builders as far as making them separate GitHub repos. This allows for independent versioning, making maintenance on CIMTool easier.
Describe the solution you'd like
Make the builders available in a standalone fashion, ideally with a small CLI interface or otherwise some API for easy programmatic calling.
Again, I think it's worth considering making them independent bits of software might be beneficial too.
Another approach is to have all builders be a new Github repository, so that a shared interface can be put on top of all of them (like LinkML does). If I were you (maintenance-wise) I would prefer one repo per builder, but that's totally your call :).
The text was updated successfully, but these errors were encountered: