Rename imaspy to imas

[prasad-sawantdesai]

renamed imaspy->imas
package name : imas-python
updated documentation
updated links which were pointing to git.iter.org
branch is tested on bamboo https://ci.iter.org/browse/IC-IG-19
pytest and documentation tested

[maarten-ic]

Hi Prasad,

That must have been quite some work! I've had a quick look at the changes, and overall it looks good. There are a couple of things that we should think about a bit better, summarized below:

1. IMASPy had some logic and content related to the legacy imas interface. Mainly in the benchmarking, tests and training material. IMO this logic and content should be removed. For one, it is technically impossible to have both the legacy and imaspy interfaces loaded after this change (since both will use the imas package name). And second, it will confuse newcomers that don't have access to the legacy interface.

   I'd suggest to review all files that come up with the following command (on the current develop branch):

   imas-python$ git grep -P '(\W|^)imas(\W|$)'

2. Should we actually rename the python module imaspy->imas? The API is not 100% compatible with the legacy imas interface (and will never be). If we rename imaspy->imas, the transition for existing codes will probably be more painful than when another module name is used:

   • Existing code will most likely break because the API is not compatible.
   • There is no way to have the legacy and the new interface available at the same time (since both need to be imported with import imas). If you have a workflow with multiple IMAS-ified python components, you need to upgrade everything at the same time, instead of allowing a gradual transition where components are updated one-by-one.

I'm happy to have a (short) discussion about this if needed. Note that I will be over at IO in two weeks, so we could do it then if there's no hurry :)

Cheers,
Maarten

[maarten-ic]

This link doesn't work

[maarten-ic]

This should be reviewed in more detail. Having the ASV benchmarks compare against the legacy imas interface doesn't make sense when renaming this package to imas.

[olivhoenen]

Hi Prasad,

That must have been quite some work! I've had a quick look at the changes, and overall it looks good. There are a couple of things that we should think about a bit better, summarized below:

1. IMASPy had some logic and content related to the legacy imas interface. Mainly in the benchmarking, tests and training material. IMO this logic and content should be removed. For one, it is technically impossible to have both the legacy and imaspy interfaces loaded after this change (since both will use the imas package name). And second, it will confuse newcomers that don't have access to the legacy interface.
   I'd suggest to review all files that come up with the following command (on the current develop branch):

   imas-python$ git grep -P '(\W|^)imas(\W|$)'

Agree on the cleaning/removing of all AL legacy mentions.

2. Should we actually rename the python module imaspy->imas? The API is not 100% compatible with the legacy imas interface (and will never be). If we rename imaspy->imas, the transition for existing codes will probably be more painful than when another module name is used:

   • Existing code will most likely break because the API is not compatible.
   • There is no way to have the legacy and the new interface available at the same time (since both need to be imported with import imas). If you have a workflow with multiple IMAS-ified python components, you need to upgrade everything at the same time, instead of allowing a gradual transition where components are updated one-by-one.

In terms of work needed in applications, keeping imaspy, moving to imas or inventing a third option won't change what needs to be done, except in the import lines. So let's use the package name that makes more sense, which is imas, and let's make sure we indicate the needed API change with the correct major release version.

I'm happy to have a (short) discussion about this if needed. Note that I will be over at IO in two weeks, so we could do it then if there's no hurry :)

Cheers, Maarten

[olivhoenen]

LGTM