esa-snap-s1tbx-gptRATIONALE
Packaging rationale

A smaller SNAP,
for reproducible SAR.

esa-snap-s1tbx-gpt exists to make ESA SNAP GPT usable as normal conda infrastructure while preserving scientific reproducibility.

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 13.0.0 -> SNAP 13.0.0
esa-snap-s1tbx-gpt 14.0.0 -> SNAP 14.0.0

Conda 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 snap10 -c sarforge -c conda-forge esa-snap-s1tbx-gpt=10.0.0
mamba create -n snap14 -c sarforge -c conda-forge esa-snap-s1tbx-gpt=14.0.0

Splitting 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:

SNAPRetained platforms
9.0.0linux-64
10.0.0linux-64
13.0.0linux-64, win-64, osx-arm64
14.0.0linux-64, win-64, osx-arm64

Linux is kept for every release because it is the most common platform for reproducible, automated, server-side processing. The two current release lines, SNAP 13 and SNAP 14, ship the broadest platform set (Linux, Windows, and Apple Silicon macOS). SNAP 11 and 12 were retired from the channel on 2026-09-24; their recipes remain in the repository.

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=true

Those defaults are added to the packaged snap.conf so gpt -h and batch workflows behave consistently on servers, CI, and notebooks.