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 Configuration Object to Semantic Manifest #95

Merged
merged 5 commits into from
Jun 26, 2023

Conversation

plypaul
Copy link
Contributor

@plypaul plypaul commented Jun 23, 2023

Resolves #94

Description

Please see the linked issue.

Checklist

@cla-bot cla-bot bot added the cla:yes label Jun 23, 2023
@plypaul plypaul requested review from tlento and QMalcolm and removed request for tlento June 23, 2023 19:01
@plypaul plypaul marked this pull request as ready for review June 23, 2023 19:09
project_configuration:
dsi_package_version: 1.2.3
time_spine_table_configurations:
- location: example_schema.example_table
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

{{project_schema}}.mf_time_spine

@marcodamore marcodamore requested a review from tlento June 23, 2023 19:25
Copy link
Collaborator

@QMalcolm QMalcolm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good

@@ -23,5 +24,10 @@ def metrics(self) -> Sequence[Metric]: # noqa: D
def interfaces_version(self) -> str: # noqa: D
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this now duplicate information? Should we remove this property in favor of dsi_package_version in project_configurations?

Copy link
Collaborator

@QMalcolm QMalcolm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More thoughts came to me after my initial review. We should never be expecting the user to to set the dsi_package_version. Thus we shouldn't be including it in the json schema spec. We should use a pydantic validator on the PydanticSemanticVersion implementation which parses it if a value is provided, otherwise it should populate the the current package version. The former change indicates to users that it isn't something they should directly set. The latter change allows for delineation between deserialization and new object instantiation.

"$id": "project_configuration",
"type": "object",
"properties": {
"dsi_package_version": {"type": "string"},
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we want the user the be able to specify the dsi_package_version. This is something that should be auto-generated from the implementation classes. See the validator that sets the interfaces_version on the SemanticManifest pydantic implementation

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you clarify how that would work? e.g. we release DSI v0.2, but the customer wrote and committed configs based on DSI v0.1. If the server is upgraded and deserializes the files, wouldn't the version be incorrect?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Deserialization and parsing logic is not the same. The JSON schema is only used for validating the yaml prior to parsing it to the object. Specifically it is invoked in the from of <object_validator>.validate(...) (example). Deserialization is the act of calling <object_type>.parse_raw(...yaml...) deserialization by itself doesn't call json schema validation. Additionally in our json schema we explicitly disallow extra keys thus if someone tries to set a dsi_package_version we want things to fail. Because deserialization doesn't do json schema validation, this is not a problem. Thus by using using a pydantic validate setter we can handle both situtiations. When going through parsing, the dsi_package_version should be None, so we auto generate it. When deserializing, the value for dsi_package_version would be included in the serialization and thus will be used.

Comment on lines 28 to 33
"""Parses a MetricInputMeasure from a string (name only) or object (struct spec) input.

For user input cases, the original YAML spec for a PydanticMetric included measure(s) specified as string names
or lists of string names. As such, configs pre-dating the addition of this model type will only provide the
base name for this object.
"""
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doc string need some updating

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated.

Comment on lines 34 to 35
if isinstance(input, str):
input_split = input.split(".")
if len(input_split) not in (2, 3):
raise ValueError(f"Expected version string to be of the form x.y or x.y.z but got {input}")
return PydanticSemanticVersion(
major_version=input_split[0],
minor_version=input_split[1],
patch_version=input_split[2] if len(input_split) == 3 else None,
)
else:
raise ValueError(
f"{cls.__name__} inputs from YAML files are expected to be of either type string or "
f"object (key/value pairs), but got type {type(input)} with value: {input}"
)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We probably want to update this to be a validator similar to

def __create_default_interfaces_version(cls, value: str) -> str: # type: ignore[misc]

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A little unclear how the validator would work in the case with the custom parser. Mind elaborating?

@plypaul plypaul force-pushed the plypaul--36--project-configuration branch from db47347 to 333469e Compare June 23, 2023 21:29
@plypaul plypaul force-pushed the plypaul--36--project-configuration branch from 333469e to 22218c8 Compare June 23, 2023 23:00
@plypaul plypaul requested a review from QMalcolm June 23, 2023 23:00
@plypaul
Copy link
Contributor Author

plypaul commented Jun 23, 2023

@QMalcolm - updated as per comments.

@plypaul
Copy link
Contributor Author

plypaul commented Jun 23, 2023

NVM, left out something.

@plypaul plypaul force-pushed the plypaul--36--project-configuration branch from 22218c8 to 5b3f00d Compare June 23, 2023 23:09
Copy link
Collaborator

@QMalcolm QMalcolm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great! Thank you so much for all the work! I know we had to go back and forth on a few things, but it worked out great 🙂

@plypaul plypaul merged commit f8dd217 into main Jun 26, 2023
5 checks passed
@plypaul plypaul deleted the plypaul--36--project-configuration branch June 26, 2023 16:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Feature] Add Configuration Object to Semantic Manifest
3 participants