IPF 1.9.6

Workflows supported by ACCESS:

• Compute
• Extmodules

No longer requires root access. Can install as a regular user on any node (login node recommended in order to pickup expected user environment).

Activity workflow is deprecated. Should still run from an existing JSON config file but configurating a new Activity workflow is not possible.

Full Changelog: 1.9.5...1.9.6

IPF 1.9.5

Support for running on a round-robin login node

Pypi friendly README

Minor updates that affect publishing pipeline only. No functional code changes.

IPF 1.9.3

• CTT-673 Remove xdresourceid references (#3)
• CTT-622 Remove references to "rpm"
• CTT-661/unique dev version string (#24)

Pip install for the win

Pip is now the officially supported install method.

Adds CI/CD via github workflows for automated publishing of dev and prod versions.

New install instructions aim to make the admin's life simpler.

IPF 1.8.4

This release introduces a new install method, install-from-github, allowing a simple install method as a regular user for the most common use case of publishing the extmodules workflow.

Also updates to the documentation split it into smaller, easier to digest chunks.

IPF 1.8.2

Fixes bug for extmodules workflow where IPF was interpreting the Application
Name to be "ApplicationName/ApplicationVersion"

1.8.1 Release

This release fixes how IPF handles an edge case that can occur in lmod_cache files (spiderT.lua) where the version of a module might not be a string.

It also formalizes the lupa dependency needed for reading lua files.

IPF 1.8.0 release

IPF v1.8 highlights:

• New option for the modules workflow for sites using Lmod. IPF can now be configured to use an lmod cache file instead of a MODULEPATH as the source of module information to be published
• RPM built with python 3.11 which should enhance compatibility
• fix for init script: su command needed a -c argument
• IPF documentation revised for clarity and completeness
• Default for support contact no longer references an XSEDE service

1.7.1

Fixes issue #2 by having the default extmodules workflow treat each directory in MODULEPATH as a top level directory, all of whose subdirectories are semantically significant, and part of the inferred module name.

The old behavior is still available by using the --modules-recurse option for ipf_configure when configuring the workflow.

This default behavior no longer excludes module files that exist directly in the top level directory (as was the old default behavior). To keep this behavior, use the --ignore_toplevel_modulefiles when configuring the workflow.