Support for different workflows

[janihur]

I'm not sure if this is a valid use case for IPM but I'm just playing with the idea IPM could be used for different workflows like:

1. development time workflow
2. deployment time workflow

but still controlled with single manifest file. The main difference of these example workflows are the extra tooling needed during the development time.

Ideas of the potentially useful supporting mechanisms:

Ensure mapping dependencies exists:

<Dependency>
  <Mapping>
    <Package>Company.Package.Foo</Package>
    <Version>1.0.*</Version>
    <!-- optionally also check the source -->
    <Database>COMPANY_PACKAGE_FOO_DB</Database>
  </Mapping>
</Dependency

Validate and install dependencies depending of the workflow (inspired by maven's dependency scoping):

<Dependency>
  <Scope>Dev</Scope>
</Dependency>

The user defines his own workflows (or scopes). This will affect also all other IPM parts like resource processors and <Invoke>.

I agree this might be just too much for the planned scope of a package manager.

[janihur]

When I was writing the issue I realized IPM already has -dev flag:

-dev Sets the DeveloperMode flag for the module's lifecycle. Key consequences of this are that ^Sources will be configured for resources in the module, and installer methods will be called with the dev mode flag set.

But I find the description hard to understand:

1. What's the point of "^Sources will be configured for resources"?
2. What are the installer methods? Lifecycle methods in resource processors?

This is probably the last piece I was missing from the existing IPM functionality that prevents me tailoring IPM for our current needs. We'll see.

You're welcome to close this issue if you don't find the ideas here fit for the tool but I still think it's useful to be able to define a dependency is only for development time.

[isc-tleavitt]

@janihur I'll agree, that doc is unhelpful. The references to ^Sources and "installer methods" are vestigial. Dev dependencies have been on my wishlist for a while too, though only captured through an internal ticket (ref for InterSystems folks: HSIEO-186).

Keeping this open to cover:

• Doc improvements
• Actually supporting dev dependencies, same as Maven/npm.

For a few examples of the workflow you're looking for, see: https://github.com/intersystems/git-source-control/blob/main/module.xml#L19 - does an additional JS build in dev mode only https://github.com/intersystems/isc-ipm-js/blob/main/cls/pkg/isc/ipm/js/base/processor.cls#L26 and https://github.com/intersystems/isc-ipm-js/blob/main/cls/pkg/isc/ipm/js/base/processor.cls#L338 - this is a bit more complex, but ultimately the behavior is that when we produce an artifact we include built UI sources, but in developer mode / when we're loading (vs. installing) we'll do an Angular/React/etc. build.

[janihur]

Thanks for the tips - this tells me someone should write a book about different IPM usage patterns :)

My conclusion for now is that I'm not going to rely on IPM for these "advanced" workflow management tasks but just use it's basic functionality to install an ObjectScript app with right dependencies. I'll extend our existing tooling (based on Python) to cover the missing workflow part. Anyway I hope to see IPM as a maven of the IRIS ecosystem some day! I might reconsider when I have read that IPM book, thought ;)

[evshvarov]

Thank you, Jani! Great feedback and requests! And also check the most popular open source libs for now: https://openexchange.intersystems.com/?sort=pm.desc Looking forward for your open source contributions on IPM to the community!

On Fri, Nov 15, 2024 at 12:25 PM Jani Hur @.***> wrote:

Thanks for the tips - this tells me someone should write a book about different IPM usage patterns :)

My conclusion for now is that I'm not going to rely on IPM for these "advanced" workflow management tasks but just use it's basic functionality to install an ObjectScript app with right dependencies. I'll extend our existing tooling (based on Python) to cover the missing workflow part. Anyway I hope to see IPM as a maven of the IRIS ecosystem some day! I might reconsider when I have read that IPM book, thought ;)

— Reply to this email directly, view it on GitHub https://github.com/intersystems/ipm/issues/624#issuecomment-2478703102, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAVHEP6M2M67WJYJDUWABHD2AXR4ZAVCNFSM6AAAAABRRNYR5KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZYG4YDGMJQGI . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[isc-tleavitt]

@janihur if you want to connect to discuss your use cases more specifically, I'm happy to - drop me an email at tleavitt at intersystems.com