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

Add extensible json config option for externally developed Services and Environments #880

Open
2 tasks
bpkroth opened this issue Nov 13, 2024 · 0 comments
Open
2 tasks

Comments

@bpkroth
Copy link
Contributor

bpkroth commented Nov 13, 2024

Right now our configs mostly look like this:

{
   "class": "mlos_bench.services.SomeKnownServiceName",
   "config": {
   // restricted set of configs based on the class
   }
}

Similar for Environments.

It should be possible to also load external classes as well, except that the schema checks reject them.

{
   "class": "mlos_bench_custom.services.SomeNewServiceNameBeingLocallyDeveloped",
   "config": {
   // UNrestricted set of configs based on the class
   }
}

We have a hack around that using an environment variable currently:

_SKIP_VALIDATION = environ.get(_VALIDATION_ENV_FLAG, "false").lower() in {

However, an alternative option that would allow local extensibility is the following:

  • Extend the schemas to also allow mostly free form config sections for class specifications under particular new namespaces (e.g., the one listed above).
  • Create your new class under that namespace and pip install it locally or else just adjusts your PYTHONPATH

This would allow local configs and classes to be developed inside the local repo and outside of the main MLOS repo.

One challenge with this is that it would be more challenging to collect new Services and Environments into the main repo unless people submit a PR, but there would now be less incentive to do that.
Not sure I have a good solution to that.

If we decide to do this:

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

No branches or pull requests

1 participant