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
How do we support downstream consumers using their own generated models crates? This requires solving a number of interesting problems:
How do consumers generate their own models? What workflows are encouraged/supported? If we're using Bazel, can we provide a rules_redfish module that exposes rules for consumers to generate models crates?
How do consumers use higher level components, like seuss, with custom models crates? Can consumers use cargo patching to override the dependencies from crates like seuss? This may require us to partition large components of seuss with feature flags, so that consumers are not required to provide models for Redfish components that they don't use.
The text was updated successfully, but these errors were encountered:
In my own exercises in extending the redfish schemas, there are at least a few different requirements I've run into:
The need to apply patches to the existing schemas
The need to extend the models with additional (external) schemas
The need to peg the model crate to a specific Redfish version
The need to include or constrain specific extensions as a model crate feature extension
Besides Swordfish, we already have the WIP Sunfish extensions from the OFA that could also be (optionally) added, and I am also in the midst of extending Redfish for automotive systems.
Here it would be useful to be able to define which extensions to enable, particularly where they have not yet been ratified/made normative by the redfish consortium, and to provide a straightforward mechanism where people who are developing their own schemas/extensions can plug this into the model crate.
Cargo patching, I think, could be a solution for the first point, but I'm not sure about the others. Here I would probably lean towards feature flags.
Just to follow up on this, there is a dependency on redfish-macros in the models crate that currently requires a relative path within the redfish-codegen workspace. As cargo presently does not provide a mechanism for including both a git tree and a path (or vendoring crates from paths), there is no way to cleanly depend on this with an external models crate. As a workaround, I split redfish-macros into its own git repo locally and was then able to use cargo vendor to pull this in to the custom models crate, allowing this to then exist standalone outside of the workspace. Could you perhaps refactor redfish-codegen to split these crates out into their own repos and then pull them in to the workspace via git submodules?
How do we support downstream consumers using their own generated models crates? This requires solving a number of interesting problems:
rules_redfish
module that exposes rules for consumers to generate models crates?seuss
, with custom models crates? Can consumers use cargo patching to override the dependencies from crates likeseuss
? This may require us to partition large components ofseuss
with feature flags, so that consumers are not required to provide models for Redfish components that they don't use.The text was updated successfully, but these errors were encountered: