Use `ruamel-yaml` `v0.18.7+` syntax

[matthewfeickert]

PR #542 demonstrated that starting in ruamel-yaml v0.18.7 there is a SemVer and API breaking change that raises

ruamel.yaml.composer.ComposerError: found undefined alias 'DEF_query'

which as of shows up in d329059

$ git grep "DEF_query"
docs/yaml.md:14:  - &DEF_query !PythonFunction |
docs/yaml.md:20:    Query: *DEF_query
docs/yaml.md:34:    Query: *DEF_query
docs/yaml.md:39:- &DEF_query !PythonFunction |
tests/test_databinder.py:549:- &DEF_query !PythonFunction |
tests/test_databinder.py:564:    Query: *DEF_query

(c.f. #540 (comment) for a full example)

I don't know anything about ruaeml-yaml, so I'm not sure how obvious of an issue and fix there is, but as it is an API breaking change I'm going to assume that it will need

ServiceX_frontend/pyproject.toml

Line 52 in d329059

"ruamel.yaml>=0.18",

to get updated to

"ruamel.yaml>=0.18.7"

with the fix.

cc @ponyisi @BenGalewsky as I think they are the most familiar with the ruaeml-yaml project(?). Maybe also @kyungeonchoi as this bug showed up in the DataBinder tests.

[ponyisi]

I more or less understand this. It's not a syntax issue, it's rather an issue with a "should have been transparent" change in the ruamel-yaml package that broke an assumption in ccorp-yaml-include-relative-path. Fixing this is going to be ... interesting.

[ponyisi]

I've submitted a patch to the upstream maintainer. This package is not particularly active, so we'll see if there's any action there. If not I will fork it for our own use.

[matthewfeickert]

I've submitted a patch to the upstream maintainer.

This PR: marsoloGit/ccorp_yaml_include#2 👍

This package is not particularly active, so we'll see if there's any action there. If not I will fork it for our own use.

That would be a fork of a fork of an unmaintained project at that point (where the fork maintainer has had no (public) GitHub activity in over a year). 😬 Also you'll need to make a new package on PyPI.

That seems not ideal to say the least. Could you instead just look at what components of the functionality you actually need and then just write a small package that does just that?

[ponyisi]

@matthewfeickert the package that we include is already more or less the minimal way to do the one thing we want it to do; at some point the easiest answer is to just pull the single code file into servicex_frontend with the fix (it's MIT license so I don't think there's a problem? you tell me).

[matthewfeickert]

at some point the easiest answer is to just pull the single code file into servicex_frontend with the fix (it's MIT license so I don't think there's a problem? you tell me).

@ponyisi Ah if it is that simple of a codebase (I hadn't looked before) then I would highly recommend doing so. That would simplify the maintainability story quite a bit. As you note, ccorp-yaml-include-relative-path is MIT licensed, so it is fine to copy the file over.

Though you will need to include the original MIT licence also. You can probably put it in a licenses directory or something noting which chunk of code is MIT licensed, or alternatively append it to the existing ServiceX client BSD-3 license, though that's a bit awkward in my mind.