optimake serve

[eimrek]

resolves #45

This PR adds the optimake serve command that

1. (Optionally) converts a raw data archive into optimade.jsonl;
2. starts an OPTIMADE API with mongomock, ingesting the optimade.jsonl.

Uses the insert_from_jsonl feature from the PR Materials-Consortia/optimade-python-tools#2094

Couple of comments:

• I thinking how i could pass in an optimade config to the API "directly", but i don't think that's possible currently, if i just want to directly use the optimade-python-tools server. I ended up just passing the config through environment variables.
• In the config, i need to pass the custom provider fields, that i currently read from the JSONL file. I am wondering if this would make sense to do in optimade-python-tools instead, considering we're passing in the jsonl anyways.
• todo: tests

Note: I also changed the default optimake command to optimake convert.

@ml-evs does this approach make sense? if you agree, i'll try to think how to add tests for this as well.

[ml-evs]

Like the approach so far @eimrek! Env vars is probably the way to go for server config for now, but we could definitely make that easier on the o-p-t side (e.g., add passable config objects everywhere that default to the global one).

Am I okay to merge Materials-Consortia/optimade-python-tools#2094 now then? Can do a release too so its easier for you to test out.

[ml-evs]

I just merged and released Materials-Consortia/optimade-python-tools#2094 if you want to try it out @eimrek! Added a few tests and made it slightly more ergonomic (allow absolute and relative paths etc), but it should allow for the same invocation as before.

[eimrek]

thanks @ml-evs, will have a test run soon.

But just to double-check, would it make sense to add something like

optimade-maker/src/optimake/serve.py

Line 46 in 556fecc

def get_provider_fields_from_jsonl(jsonl_path: Path):

to optimade python tools instead?

Basically, just so if you pass in a jsonl file, it also takes the provider fields from there. And possibly ignores the provider fields from the config files.

Happy to move this to o-p-t, if there is a clear way to do it.

[ml-evs]

thanks @ml-evs, will have a test run soon.

But just to double-check, would it make sense to add something like

optimade-maker/src/optimake/serve.py

Line 46 in 556fecc

def get_provider_fields_from_jsonl(jsonl_path: Path):

to optimade python tools instead?

Basically, just so if you pass in a jsonl file, it also takes the provider fields from there. And possibly ignores the provider fields from the config files.

Happy to move this to o-p-t, if there is a clear way to do it.

Yeah I think we can consider that now, just didn't want to hold you up on this PR. It would be doable, but I think essentially the JSONL loading process will have to update the global CONFIG object for this to work smoothly for now. I can have a play around with it too.