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

Update/use ProblemConfig #353

Open
wants to merge 2 commits into
base: develop
Choose a base branch
from
Open

Conversation

dweindl
Copy link
Member

@dweindl dweindl commented Dec 20, 2024

  • add to_yaml
  • refactor model, avoid extra elements in object tree
  • use ProblemConfig in petab1to2

* add to_yaml
* refactor model, avoid extra elements in object tree
* use ProblemConfig in petab1to2
@dweindl dweindl requested a review from a team as a code owner December 20, 2024 14:21
@codecov-commenter
Copy link

codecov-commenter commented Dec 20, 2024

Codecov Report

Attention: Patch coverage is 93.10345% with 2 lines in your changes missing coverage. Please review.

Project coverage is 74.83%. Comparing base (ec58463) to head (6d89e04).

Files with missing lines Patch % Lines
petab/v1/problem.py 80.00% 2 Missing ⚠️
Additional details and impacted files
@@             Coverage Diff             @@
##           develop     #353      +/-   ##
===========================================
- Coverage    74.89%   74.83%   -0.06%     
===========================================
  Files           56       56              
  Lines         5604     5600       -4     
  Branches       982      982              
===========================================
- Hits          4197     4191       -6     
- Misses        1033     1035       +2     
  Partials       374      374              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@dweindl dweindl self-assigned this Dec 20, 2024
Copy link
Member

@dilpath dilpath left a comment

Choose a reason for hiding this comment

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

👍

condition_files: ListOfFiles = []
observable_files: ListOfFiles = []
visualization_files: ListOfFiles = []
sbml_files: list[str | AnyUrl] = []
Copy link
Member

Choose a reason for hiding this comment

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

This can be list[Path | AnyUrl], since pydantic has native support for pathlib.Path IIRC. But then you might need to make a custom path object that serializes to string https://github.com/dilpath/mkstd/blob/fb4ebfda629b0fb9eedb1def5ab05438ab85696e/mkstd/types/path.py

Fine as is, just noting in case it becomes useful later

Comment on lines 1218 to 1219
filename: Destination file name. The parent directory will be created
if necessary.
Copy link
Member

Choose a reason for hiding this comment

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

Not in __all__ so I guess it doesn't matter for docs, but usually this style in this repo

Suggested change
filename: Destination file name. The parent directory will be created
if necessary.
Parameters:
filename:
Destination file name. The parent directory will be
created if necessary.

.. I think. In the files touched by this PR alone, I see

Parameters
----------

Arguments:

Parameters:

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, it would make sense to start a style guide....

I'd prefer :param ...:

Copy link
Member

Choose a reason for hiding this comment

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

Agreed, but no preference for the specific style

@@ -1024,7 +1023,17 @@ class ProblemConfig(BaseModel):
description="The base path to resolve relative paths.",
exclude=True,
)
format_version: VersionNumber = "2.0.0"
format_version: str = "2.0.0"
Copy link
Member

Choose a reason for hiding this comment

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

str | int in v1 -- intentional difference?

Copy link
Member Author

Choose a reason for hiding this comment

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

That's how it is in the current schema draft. Although not strictly enforced so far, I think it would make sense to always require major.minor. But that's probably a separate discussion.

Copy link
Member

Choose a reason for hiding this comment

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

Since there is no benefit to keeping 1 as an int, could use str instead of str | int, to use pydantic to handle the type casting.

Requiring a full version string is fine for me, but then we need to provide schemas for each minor version. Makes sense to support minor updates to the format, so I'm also in favor of expecting a full X.X or X.X.X string. major.minor` as suggested is probably enough since we probably don't need to distinguish "minor" and "patch" updates

Copy link
Member Author

Choose a reason for hiding this comment

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

Agreed, but I'll keep that for a future update.

def to_yaml(self, filename: str | Path):
"""Write the configuration to a YAML file.

filename: Destination file name. The parent directory will be created
Copy link
Member

Choose a reason for hiding this comment

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

Same doc comment re: Parameters:

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

Successfully merging this pull request may close these issues.

3 participants