Dear PEtab community,
thank you for feedback on the proposed changes to the PEtab standard that introduces extensions. We received 10 responses (8 Positive, 1 Abstained, 1 Revision). The suggested revisions are provided below (R) with inline comments (C):
R: Re: regex for extension name: `^[a-zA-Z_]\w*$`
- Is it normal to start with an underscore? Seems unusual
- I think "\w" usually doesn't include hyphens, right? Perhaps hyphens should be included. e.g.: PyPI (for any Python-based PEtab extensions) converts underscores to hyphens.
C: We updated the regex to not exclude initial underscore and include hyphens.
R:- Re: "PEtab extensions required for interpretation of a problem specification must
be specified in the PEtab-YAML files"
- How does this work for extensions that act on sets of PEtab problems (e.g. where it doesn't make sense to add new specification files to the PEtab YAML file). Then the PEtab problem files are "independent" of the extension files. e.g. PEtab Select
C: We added a paragraph in the documentation that explains that such situations should be handled by referencing the different PEtab files in the extension specific fields in a blank PEtab problem file.
R: - Perhaps a contradiction, two quotes from the proposal:
- "List two toolboxes that support the proposed standard"
- "There is at least one tool that supports the proposed extension"
C: We updated the proposal to consistently only require one implementation
R: - Re: "The developers submit a pull request that adds test cases to validate support
for the extension in the
https://github.com/PEtab-dev/petab_test_suite"
- Might result in duplication of a test suite between the PEtab extension repository and the "petab_test_suite" repository.
- Could they be somehow symlinked e.g. a git submodule etc?
- Are the tests there setup to provide informative feedback (e.g. do the tests have tags?) or allow developers to easily "ignore" tests that they know will fail (e.g., a developer might want to only test against all purely PEtab core tests with a tag whitelist or blacklist, or parallelize tests in CI workflows by splitting by extensions (and thereby package dependencies))
- One possibility would be to organize tests into subfolders by extension name
C: We have revised the specification and now request the test suite to be provided in the extension specific library.
R: - "If at least 50% of the votes are in favor"
- probably not necessary, but was a quorum considered?
- e.g. if only 1 person votes, in favor, then the extension gets accepted?
C: We updated the documentation to clarify that there is no quorum number for the vote. We anticipate that at least all members of the editorial board will participate in the vote.
Thank you again for your participation,
Fabian Fröhlich,
on behalf of the PEtab editors