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

Library organization for petab v2 #271

Open
dweindl opened this issue Jun 25, 2024 · 4 comments · Fixed by #282
Open

Library organization for petab v2 #271

dweindl opened this issue Jun 25, 2024 · 4 comments · Fixed by #282

Comments

@dweindl
Copy link
Member

dweindl commented Jun 25, 2024

We are planning for a PEtab v2 release, ideally within the next 6 months. An open question is how to handle that in libpetab, as there will be quite some incompatible changes. This issue is to discuss/outline how we accommodate these changes here.

The goal should be to support PEtab v1 and PEtab v2 files in parallel. We should be able to validate both v1 and v2 files and there should be some functionality to up-convert PEtab v1 problems.

My current idea would be to have petab.v1 and petab.v2 subpackages, that can be imported with import petab.v1 as petab and be used without (or very few) adaptions. This will imply some code duplication, but I still think it will be more maintainable.

I would go for a libpetab 1.0 release where we clarify the public API and move code to a petab.v1 subpackage.
I am not sure if we want to keep things importable from petab directly. I tend to require import petab.v1 as petab.

@dilpath
Copy link
Member

dilpath commented Jun 25, 2024

The suggestion of petab.v1/v2 sounds best to me. And I would also be in favor for requiring import petab.v1 as petab. Is a deprecation period possible for this major change? We could add from .v1 import * to petab/__init__.py I guess.

Things like petablint will require version information as well, unless the problem YAML with version information is supplied. Or would we also rename that to petablint.v1/v2?

@dweindl
Copy link
Member Author

dweindl commented Jun 25, 2024

Is a deprecation period possible for this major change? We could add from .v1 import * to petab/__init__.py I guess.

Yes. And introduce petab.v1 rather sooner than later, so that consumers can already adapt to that.

Things like petablint will require version information as well, unless the problem YAML with version information is supplied. Or would we also rename that to petablint.v1/v2?

I think the main use case is running petablint on a full petab problem where the version number would be available from the yaml file. I am not sure how many people are running it on individual files where validation is anyways rather limited.
Either we add a version option for validation of individual files, or – preferred – only handle full petab problems (and make the -y optional and remove it at some point).

@dilpath
Copy link
Member

dilpath commented Jun 25, 2024

Either we add a version option for validation of individual files, or – preferred – only handle full petab problems (and make the -y optional and remove it at some point).

Makes sense, then we could deprecate validation of individual tables already, with some message asking for feedback if someone needs it.

@dweindl
Copy link
Member Author

dweindl commented Jun 25, 2024

we could deprecate validation of individual tables already

#274

Please post any feedback specific to the adaptation of petablint there.

dweindl added a commit that referenced this issue Jun 28, 2024
As discussed in #271, we need to accommodate the changes related to the upcoming PEtab v2. The goal is to move PEtab 1.0 functionality to a `petab.v1` subpackage and PEtab 2.0 functionality to a `petab.v2` subpackage.

This PR moves (almost) all code from the `petab` package to a `petab.v1` sub-package. Keeps all non-private objects importable from their previous location, but issues `DeprecationWarnings`.

**From the next release on, all consumers should change all `from petab[.$x] import $y` to `from petab.v1[.$x] import $y`.**

Fixes a couple of sphinx-issues that occurred on the way. Some obscure sphinx-failures remain, but they aren't critical.

Also adds some missing `__all__`s.
@dweindl dweindl linked a pull request Jun 28, 2024 that will close this issue
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 a pull request may close this issue.

2 participants