Why keep old SNAP versions
SNAP versions are part of a scientific workflow, not just a convenience layer. Older versions can matter because:
- published methods may have been validated with a specific SNAP release;
- graph XML files can depend on operators and defaults from that release;
- processor behavior, auxiliary-data handling, and toolbox internals can change;
- teams often need to reproduce older Sentinel-1 products for comparisons or audits.
esa-snap-s1tbx-gpt 11.0.0 -> SNAP 11.0.0
esa-snap-s1tbx-gpt 13.0.0 -> SNAP 13.0.0Conda build numbers are reserved for packaging-only fixes.
Why one package name
Using one package name and one channel gives users a trusted, homogeneous install pattern:
mamba create -n snap11 -c sarforge -c conda-forge esa-snap-s1tbx-gpt=11.0.0
mamba create -n snap13 -c sarforge -c conda-forge esa-snap-s1tbx-gpt=13.0.0Splitting historical versions across unrelated channels would make old builds look unofficial or second-class. Keeping the same name, channel, metadata, tests, and layout is the trust signal.
Why a pruned SAR/GPT package
The package targets headless SAR processing, not the full desktop SNAP experience. The build keeps:
- SNAP engine and
gpt; - Sentinel-1 Toolbox,
s1tbx; - Radar/Polarimetric Toolbox,
rstb; - shared microwave/SAR support;
- the normal SNAP directory layout so tools can auto-detect it.
The optical Sentinel-2/3 clusters are removed because they are large and outside this package's SAR/GPT purpose.
Why the matrix is smaller than upstream
Anaconda.org free storage is limited, while SNAP installers are large. The public sarforge channel therefore keeps a deliberate matrix:
| SNAP | Retained platforms |
|---|---|
| 9.0.0 | linux-64 |
| 10.0.0 | linux-64 |
| 11.0.0 | linux-64 |
| 12.0.0 | linux-64 |
| 13.0.0 | linux-64, win-64, osx-arm64 |
Linux is kept for old releases because it is the most common platform for reproducible, automated, server-side processing. SNAP 13 keeps the broadest platform set because it is the current release line.
Why not conda-forge yet
This package currently repackages upstream installer binaries. That does not fit the normal conda-forge expectation that packages are built from source in the feedstock.
A future source-built feedstock may be possible, but this repository focuses on a practical, reproducible conda distribution of the official SNAP runtime.
Prior art
The project should be understood as part of a longer SNAP automation ecosystem, not as a first attempt at conda packaging. In particular, snap-contrib/snap-conda showed that SNAP could be distributed through conda for unattended Linux/headless use.
esa-snap-s1tbx-gpt differs by narrowing the scope to headless gpt and the SAR stack, preserving multiple SNAP versions for reproducibility, keeping a pyroSAR-friendly layout, and documenting a retained public platform matrix.
Runtime defaults
SNAP is a desktop application platform even when only gpt is used. In headless Linux environments, startup can trigger update/version-check or desktop initialization paths that are not useful for batch processing.
-J-Dsnap.versionCheck.interval=NEVER
-J-Djava.awt.headless=trueThose defaults are added to the packaged snap.conf so gpt -h and batch workflows behave consistently on servers, CI, and notebooks.