-
Notifications
You must be signed in to change notification settings - Fork 7
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
Comments
The suggestion of Things like |
Yes. And introduce
I think the main use case is running |
Makes sense, then we could deprecate validation of individual tables already, with some message asking for feedback if someone needs it. |
Please post any feedback specific to the adaptation of |
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.
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
andpetab.v2
subpackages, that can be imported withimport 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 requireimport petab.v1 as petab
.The text was updated successfully, but these errors were encountered: