Renaming. Can we keep globals with the same ZPM name?

[evshvarov]

I installed the current build of ZPM with changed global storage into the system with the previous version of ZPM installed. And the installation doesn't work.
We need to consider a converter included when installing IPM over ZPM.

Or could we keep global names the same?
Reasoning:

1. nobody in fact cares what globals are behind the app. E.g. globals for persistent classes are random in the latest IRIS.
2. we will keep zpm command and $zpm function for IPM usage.
3. we'll get rid of the conversion problem at all.

[isc-kiyer]

For point 1, I agree we could perhaps keep the same global name for most cases to ease migration from ZPM to IPM. We will however, have to change a few storage globals to make IPM namespace specific. For example, with repositories, the storage is instance wide in a % global. Need to drop the % there and migrate to a non-% globals.

For point 2, I agree we can keep the zpm command as is. What is the $zpm function?

For point 3, Also, we will anyway need a migration script as we need to delete all %ZPM classes during the migration so that studio document classes don't conflict (will cause issues if we have both a %ZPM and %IPM class for the same studio document extension).

[bg-ssh]

What is the $zpm function?

Same as command, but you can examine return value

[grongierisc]

I hope with IPM we will be keeping ZPM command for retro compatibility reason.

Moreover, will IPM remain an opensource project like VsCode plugins and iKnow with a release rate independent from IRIS??

[isc-rsingh]

Yes @grongierisc. That is the intention.

[evshvarov]

$zpm() function let’s you run zpm command and get the result in a form of %Status of the installation back. e.g. set sc=$zpm(“install package”) It’s very handy for image creation, dev environment, testing and deployment scenarios. Чт, 16 июня 2022 г. в 18:05, isc-kiyer ***@***.***>:

…

For point 1, I agree we could perhaps keep the same global name for most cases to ease migration from ZPM to IPM. We will however, have to change a few storage globals to make IPM namespace specific. For example, with repositories, the storage is instance wide in a % global. Need to drop the % there and migrate to a non-% globals. For point 2, I agree we can keep the zpm command as is. What is the $zpm function? For point 3, Also, we will anyway need a migration script as we need to delete all %ZPM classes during the migration so that studio document classes don't conflict (will cause issues if we have both a %ZPM and %IPM class for the same studio document extension). — Reply to this email directly, view it on GitHub <#327 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAVHEP3SNPDI57YGYTXVXRDVPMYBRANCNFSM5Y6CAKUA> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>