Enable use of external SOFA and SOFA plugins

[RafaelPalomar]

💡 Background

During discussions at SOFA Week, we identified the need to make Slicer-SOFA more accessible for users who create their own SOFA plugins (e.g., the SOFA community). Ideally, Slicer-SOFA should serve a dual purpose:

1. Equipping Slicer with a powerful physics/simulation engine.
2. Providing SOFA with a rich environment for interacting with medical data.

Key Points:

• Slicer-SOFA was initially developed with Slicer users in mind.
• Many SOFA users develop custom plugins for their projects, which they may wish to integrate into Slicer.
• The SOFA community maintains a rich ecosystem of off-tree plugins, some of which have restrictive licenses (e.g., GPL), making them unsuitable for direct bundling with Slicer-SOFA (see Slicer/SlicerSOFA#30).
• Bundling too many plugins directly into Slicer-SOFA could increase its maintenance overhead as these plugins are living projects.

---

🔧 Alternatives Considered

1️⃣ Add Configuration Settings for SOFA and SOFAPython3

• Summary: Allow users to configure the selection of SOFA and SOFAPython3.
• Challenges:
  • Configurations could be added at the Slicer settings level (which may require a pluggable settings mechanism, as discussed in the Slicer Developer Meeting) or at the Slicer-SOFA module level (currently hidden with no UI).
  • Adds complexity due to the need for managing user-specific files/folders and possibly expanding core Slicer functionality to handle plugin-owned settings.
  • Not recommended due to the added development and maintenance overhead.

---

2️⃣ Wrap SOFA Plugins as Slicer Extensions

• Summary: Allow SOFA plugins to leverage the libraries deployed by Slicer-SOFA by wrapping them as Slicer extensions.
• Advantages:
  • Ideal for developers focusing on medical applications requiring specific plugins not distributed with Slicer-SOFA.
  • Slicer's CMake infrastructure simplifies discovery and linking of SOFA libraries.
  • Reduces maintenance for Slicer-SOFA by keeping plugins modular and independent.
  • Highly recommended for expanding interoperability.

---

3️⃣ Use Environment Variables to Optionally Select SOFA Core and SOFAPython3

• Summary: Allow users to set an environment variable (Slicer_SOFA_ROOT) to specify a custom SOFA installation.
• Advantages:
  • Requires minimal changes to Slicer-SOFA.
  • A good entry point for the SOFA community to test their own versions of SOFA without modifying Slicer-SOFA directly.
• Proposed Change: Update the current Slicer-SOFA implementation to check the Slicer_SOFA_ROOT variable before loading the default SOFA environment (as explained in Slicer-SOFA Environment Loading Code).
• Should also consider multiple platforms (see Slicer/SlicerSOFA Issue #30 )

---

🛠️ Possible Implementation Steps

I suggest focusing on (2) and (3), as together they accommodate all scenarios we have discussed and require minimal changes and maintenance.

1. Wrap SOFA Plugins:
   • Document the process for wrapping SOFA plugins as Slicer extensions.
   • Develop templates/examples for plugin wrapping.
2. Modify Environment Loading:
   • Extend Slicer-SOFA to check the Slicer_SOFA_ROOT variable before loading the default environment.

---

🎯 Benefits

• 🌍 Foster interoperability between Slicer and SOFA communities.
• 🛠️ Simplify workflows for developers by reducing redundant setup efforts.
• 💡 Expand the use cases for Slicer-SOFA, attracting more users and contributors.

---

🔗 References

• Slicer Developer Meeting Discussion
• Slicer-SOFA Environment Loading Code
• Slicer/SlicerSOFA Issue #30
• Slicer/SlicerSOFA Issue #30

---

🙏 We Need Your Input!

• Are there other alternatives to consider? (@bakpaul, @pieper, @lassoan, @jcfr)

Let’s work together to make Slicer-SOFA even more powerful and versatile! 🚀