Thanks, @John Murray !

I made it work by manually filing the server in a docker container.

The IPM browser works nicely! 

And it beautifully displays what is installed in the namespace.

But I wasn't able to install any app, e.g. tried with Webterminal:

1. Yes, but it can add some automation, as for docker-way port can be a random everytime, so this mean manual setup every build. Which is easy to setup, but every time.

2. Yes, UI Integration. And, if we are talking about client-side editing it is possible to edit those files manually (they are just XML files) of course. But ideally, the developer could call a UI in IRIS to edit the file from within a file, and the changes be saved into this file after editing in the IRIS UI app.

3. What exactly is "incorrect"? ) git-source-control perfectly works as a tool to deliver changes made in IRIS developer UI tools into client-side files. Well, you can say that it is server-side editing, and I agree, as every IRIS-driven developer UI tool is on the IRIS side, meaning server-side in this case. But still, it works perfectly and doesn't demand developers to change their client-side approach to a server-side in this case.

It is possible to deploy frontend/fullstack apps via IPM. Take a look e.g. this or this one.

There is also a helper package for js-based frontend by @Timothy Leavitt, which suggests yet another approach.

Great app! Why not to add IPM package deployment?

Thanks for introducing it, @John Murray !

How does it work with docker dev environment?

I launched the basic docker environment via this basic template and don't see the functionality, though have Server Explorer working:

So: for everyone who tries it via IPM - works ONLY if installed in %SYS.

Otherwise it installs itself but doesn't work silently.

installed as IPM module into USER - doesn't work.

Installed after that into %SYS - works. Any ideas?

I use VSCode client-side coding with IRIS every day. Caveats:

1. it'd be great to ease connection to a dockerised IRIS - especially if docker-compose file is not in the root. Anyway the settings.json is a mandatory component, though it can be just the same all the time.

2. Saving changes for UI elements to changed local files for some components of Interoperability and IRIS BI is not complete. For example, editing pivots in the analyzer, term lists, lookup files, etc.

3. git-source control becomes a must-have for client side editing - especially for UI elements. Maybe we could consider some functionality a mandatory part of ObjectScript extension?

Great stuff, @Dmitry Maslennikov ! 

What are the benefits compared to Web Terminal?

The article is VERY modest. Do you want to share anything else more than how to install the app?

Hi @Andrii Mishchenko !

Made it running, but see the following:

Also registered a user.

Saw Register menu as well, registered there and still cannot sign in. 

Any hint on how to proceed?

Sounds like a good idea to implement

Is it embedded python or iris python native? (I always mess with them). If the first, try the following for the system:

; enabling callin for Embedded Python

do ##class(Security.Services).Get("%Service_CallIn",.prop)

set prop("Enabled")=1

set prop("AutheEnabled")=48

do ##class(Security.Services).Modify("%Service_CallIn",.prop)

Very convenient! 

Also if you want to read any CSV, create a class out of it and load the data give it a try to others two options:

1. csvgen - an objectscript module that lets you read, create class, and load data from an arbitrary CSV in one command.

2. csvgen-python - same as csvgen but written in embedded python.

Great story, @Eduard Lebedyuk ! Could you please release your app on OEX so that IPM users could benefit from this addon as well?

Thanks for the great feedback, @Sean Connelly ! Currently, DC AI is focused on DC knowledge only, which is limited, of course. Great idea about expanding the DC AI knowledge base with ObjectScript basics - we'll consider that in future releases.