search

PEtab-dev / libpetab-python

Python package for working with PEtab files
https://libpetab-python.readthedocs.io
MIT License
14 stars 5 forks source link

Library organization for petab v2 #271

Open dweindl opened 1 week ago

dweindl commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

we could deprecate validation of individual tables already

https://github.com/PEtab-dev/libpetab-python/pull/274

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