Task #3130
Task #2045: API design and language bindings
Feature #2993: Scalar and structured type expression and definitions for API
Interim handling of gmxapi data references.
Description
The implicit behaviors described in early gmxapi 0.1 candidates have become untenable.
We delayed design of the gmxapi typing system and data model, and have gotten bogged down in various semantic ambiguities for gmxapi data topology and how to handle Python native types, along with the combinatoric explosion of the provisional annotations for data arrays, futures, and ensembles.
Until we can introduce a proper typing system and updated data model, triage amounts to making the current behavior and capabilities unambiguous and well documented.
Tasks
- identify unsupported data flow topologies or conversions.
- apply explicit handling of sequence types for arrays and ensembles in gmxapi package functions.
Deferred to other efforts under the parent task¶
- define implicit behaviors that reduce syntax requirements.
- expose core gmxapi data types to Python.
- update gmxapi Python static and dynamic type checking. Replace native Python type annotations with gmxapi type annotations in gmxapi package.
- allow explicit definition of input names and types (instead of relying exclusively on Python function signature introspection).
- implement C++ based self-describing managed gmxapi data references.
Related issues
Associated revisions
History
#1 Updated by Eric Irrgang over 1 year ago
- Description updated (diff)
#2 Updated by Eric Irrgang over 1 year ago
- Private changed from Yes to No
#4 Updated by Eric Irrgang over 1 year ago
- Blocks Bug #3136: gmxapi.operation data flow topology unclear or incomplete added
#5 Updated by Paul Bauer over 1 year ago
given that the beta is scheduled to happen in the next few days (originally today), do you think all of this will still make it in there?
#6 Updated by Eric Irrgang over 1 year ago
- Related to Bug #3150: gmxapi data type annotations are confusing and inadequate added
#7 Updated by Eric Irrgang about 1 year ago
- Target version changed from 2020-beta2 to 2020-beta3
#8 Updated by Paul Bauer about 1 year ago
- Target version changed from 2020-beta3 to 2020-rc1
is there anything going to happen for 2020 still? Or should it be bumped to 2021?
#9 Updated by Eric Irrgang about 1 year ago
Paul Bauer wrote:
is there anything going to happen for 2020 still? Or should it be bumped to 2021?
I think the required user interface changes necessary for a quick fix are inappropriate, and a better fix is not feasible without substantial changes inappropriate for this stage of the release process. I suspect we will have to consider this a documentation issue for release-2020 / gmxapi 0.1, and redirect efforts to a cleaner gmxapi 0.2 early in the new year.
#10 Updated by Mark Abraham about 1 year ago
Eric Irrgang wrote:
Paul Bauer wrote:
is there anything going to happen for 2020 still? Or should it be bumped to 2021?
I think the required user interface changes necessary for a quick fix are inappropriate, and a better fix is not feasible without substantial changes inappropriate for this stage of the release process. I suspect we will have to consider this a documentation issue for release-2020 / gmxapi 0.1, and redirect efforts to a cleaner gmxapi 0.2 early in the new year.
Sounds wise
#11 Updated by Eric Irrgang about 1 year ago
- Target version changed from 2020-rc1 to 2021-infrastructure-stable
Update gmxapi.version module.
Refs #3130
Change-Id: Iea6ba1b9cc3cf1b1ef6de71cd8ae5d9c593146c3