Remove pydantic-yaml as dependency

[agoscinski]

The amount of functionality we use of this library is extremely minimal. We replace it with the dependency ruamel.yaml that parses the yaml file into a python object. This is basically the code we use from the dependency https://github.com/NowanIlfideme/pydantic-yaml/blob/130569dabbe9843771bc6f7d52830e061238d61b/src/pydantic_yaml/_internals/v2.py#L217-L242

Furthermore, the library still uses pydantic API v1 for validating the pydantic model which is deprecated so we can replace it with pydantic v2. In addition this change gives us more flexibility as it separates the parsing of the yaml file and the validation through pydantic.

To have a similar utility function that can be used in the docstring tests we implement validate_yaml_content.

[leclairm]

Why importing locally to the function? This will be executed each time the function is called.

[agoscinski]

So I kind of imitated the style before. I think @DropD introduced this in a PR. My understanding is that this is only loaded if the function is called (and then cached so rerunning is not an issue). This makes it faster to do a top level import (import sirocco) since not all dependencies that are used in the library are immediately loaded. I am not sure about a guideline here. It makes sense to do it for ruamel since it will be only needed in a few places and importing it can take some time, but if for TypeAdapterand StringIO I am not sure if makes such a difference. Maybe @DropD has a comment or correction.

[leclairm]

Also, it hides in the function what the module depends on. Curious about @DropD thoughts on that.

[leclairm]

Other than my small comment I'm fine with the PR. I thought pydantic-yaml was developped by the same people as pydantic but apparently not. Hence the lag in using v2 I guess.

Also may I ask why ruamel.yaml?

[agoscinski]

Also may I ask why ruamel.yaml?

I just used the library that pydantic-yaml was using. We have now the flexibility to change it but I did not investigate the differences. Since it is used with particular options YAML(typ="safe", pure=True). One could definitely improve this in the future, for example, pure=True uses the default standard Python implementation to load the yaml which is more compatible over systems over using the C-extension but is also slower. I would investigate this in the future when we have a more robust CI (including CI on alps) that could catch potential errors when switching to less compatible implementation. I should make an issue for this.

[leclairm]

I should make an issue for this

Thanks for the explanation but don't bother, this is really low priority.

[GeigerJ2]

LGTM

[agoscinski]

We decided to move the imports to the header for better overview, the advantage of not importing ruamel when using the library only with the python API is not really meaningful for us. So to have a better overview is more important