Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom models crates #8

Open
2 tasks
AmateurECE opened this issue Mar 18, 2024 · 2 comments
Open
2 tasks

Custom models crates #8

AmateurECE opened this issue Mar 18, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@AmateurECE
Copy link
Owner

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.
@AmateurECE AmateurECE added the enhancement New feature or request label Mar 18, 2024
@pmundt
Copy link
Contributor

pmundt commented Aug 6, 2024

In my own exercises in extending the redfish schemas, there are at least a few different requirements I've run into:

  1. The need to apply patches to the existing schemas
  2. The need to extend the models with additional (external) schemas
  3. The need to peg the model crate to a specific Redfish version
  4. 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.

@pmundt
Copy link
Contributor

pmundt commented Aug 23, 2024

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants