[Blueline] ICON with Granule deployment

# [Blueline] ICON with Granule deployment - Shaped by: Enrique, Hannes - Appetite (FTEs, weeks): - Developers:  ## Learnings - Not difficult to learn how to build ICON UENV on santis & balfrin - in the context of a staged spack package, `uv` does not respect `spack`-installed python packages. - `uv sync` ~~does not have any option~~ (`--inexact` + `--no-install-package <xyz>` for spack python packages, reproducibility with spack dependencies + lock file) ~~to this effect~~ - `uv venv --system-site-packages ...` followed by `uv install`: - should, but does not respect the spack view's site-packages - does not respect `.pth` files in the venv's site-packages either - icon4py requires a newer version of `uv` than provided by spack (`py-uv`) - which requires a newer version of `rust` than provided by spack - which requires a newer version of `rust-bootstrap` than provided by spack - none of these are hard to add locally ## Problem It is unclear at this point what would be the best way to package and deploy in production the ICON Fortran model using the GT4Py dycore granule pre-compiled for maximum performance. There are already uenvs available to work with ICON on Alps, but they are missing the python dependencies for Icon4Py and the cache of pre-compiled gt4py-generated C++ programs. ## Appetite 1 Cycle ## Solution This is a research project on how to use the existing tools for users to bundle and deploy their software in Alps, together with the ICON Fortran code and the Icon4Py dycore granule. The expected outcome is a prototype of a tool to create a safe and fast deployment package in Alps. Since the ICON Fortran code has already support for Spack, and uenvs use Spack under the hood, the starting point should be the combination of [uenv](https://eth-cscs.github.io/cscs-docs/build-install/uenv/) with [pre-compiled uv virtual envs](https://docs.astral.sh/uv/guides/integration/docker/#optimizations) similar to using [squashfs images for python venvs](https://eth-cscs.github.io/cscs-docs/guides/storage/#many-small-files-vs-hpc-file-systems). Once the base stack of Fortran + Python dependencies is figured out, the next step is to add the gt4py cache of compiled programs into the deployable image. ## Ideas - Start from C2SM (Matthieu) uenv - Read compile-time parameters required for pre-compilation - CLI tool to drive & inject precompiled gt4py programs in the image ? ## Rabbit holes  ## No-gos - Try to rewrite the existing build system of the packages ## Progress  - [x] Go through the process of building a uenv - [x] skim [stackinator docs](https://eth-cscs.github.io/stackinator/) - [x] look through official recipes - [x] build an existing recipe - [X] create and build a new recipe with just a Python venv in it (containing some python package, maybe GT4Py?) - [x] keep notes of lessons learned, potential future issues, etc - [ ] Prototype a ICON + Granule uenv - [x] Find and build C2SM ICON uenv recipe - [x] on santis https://github.com/C2SM/software-stack-recipes/tree/main/recipes/icon/25.2/gh200 - [x] on balfrin https://github.com/C2SM/software-stack-recipes/tree/main/recipes/icon/25.2/a100 - [x] Experiment with adding a Python venv containing ICON4Py on top of the ICON uenv - [x] create a spack recipe for "just" icon4py, just enough to run py2f - [x] add the py2f command to that recipe and make the resulting files findable for other packages - [ ] Experiment with pre-compiling ICON4Py stencils separately from the uenv - [ ] Experiment with adding pre-compiled stencils to uenv - [ ] Shape full-featured uenv project for future if necessary - [ ] Analyze how to proceed for stencil pre-compilation - [ ] Discuss usecase requirements for pre-compiled stencils for MCH as well as EXCLAIM / C2SM - [ ] Maybe experiment with uenv variants (based on how stencils should be pre-compiled) - [ ] Possibly shape pre-compilation CLI tool project for future