segment-geospatial 1.4.2 declares itself Pre-Alpha and leaves its dependencies dynamic

A published, packaged 1.4.2 still declares itself Pre-Alpha

The project metadata lists the classifier `Development Status :: 2 - Pre-Alpha`, next to a version of 1.4.2 and a MIT license.

Everything else in the repository reads as later than that. There is a Journal of Open Source Software paper with a DOI, Wu and Osco in 2023, volume 8 issue 89 article 5663, and a second paper on applying SAM to remote sensing in the International Journal of Applied Earth Observation and Geoinformation. The package is on PyPI and on conda-forge with its own feedstock, and there is a Docker Hub image. Three releases shipped in 2026 alone: v1.4.0 on 2026-06-21, v1.4.1 on 2026-07-04 and v1.4.2 on 2026-08-22. The last push on record is 2026-11-02 and the repository is not archived.

The classifier is the one place in the metadata that says otherwise, and anyone reading it as a maturity signal will be misled in both directions.

Dependencies are dynamic and no setup.py appears in the tree

The build system requires setuptools 64 or newer and setuptools_scm 8 or newer. The version is written out literally as 1.4.2, and dependencies are declared dynamic, which in the setuptools world means they have to come from somewhere other than the table you can see.

No `setup.py` or `setup.cfg` appears among the repository entries. What does appear is a flat `requirements.txt` with seventeen packages, none of them pinned: gdown, geopandas, huggingface_hub, matplotlib, numpy, opencv-python-headless, patool, Pillow, pyproj, rasterio, segment_anything, shapely, smoothify, torch, torchvision, tqdm and xyzservices.

That list is not the same as the `core` extra in pyproject.toml. The extra carries twelve entries and no matplotlib, no torchvision, no smoothify and no xyzservices. So the repository holds four dependency declarations, pyproject extras plus three requirements files, and the two that a newcomer would read first do not describe the same install.

The recommended install path creates an empty project

The Installation section opens by recommending pixi over conda and mamba, on the grounds that it resolves dependencies faster and avoids common numpy version conflicts, and it is the recommendation aimed at Windows and at PyTorch, CUDA and SAM 3 setups. The quick start is this:

# Install pixi (Linux/macOS)
curl -fsSL https://pixi.sh/install.sh | sh

# Or on Windows (PowerShell)
powershell -ExecutionPolicy Bypass -c "irm -useb https://pixi.sh/install.ps1 | iex"

# Create a new pixi project
pixi init geo
cd geo

# Edit pixi.toml with your configuration (see docs for GPU/CPU examples)
# Then install
pixi install

# Start Jupyter Lab
pixi run jupyter lab

Two things to notice. The first documented step pipes a remote script straight into a shell. And the project that gets created is empty: nothing in the snippet adds segment-geospatial to `pixi.toml`, and the comment hands the configuration to the documentation instead.

Ten extras, and text prompts live outside the version you install

The pip section documents ten install targets: the bare package or `[samgeo]` for the minimum, then `[samgeo2]`, `[samgeo3]`, `[fast]`, `[hq]`, `[text]`, `[fer]`, `[api]`, and finally `[all]` and `[extra]`, which the file calls two optional imports. One command covers any of them:

pip install "segment-geospatial[samgeo3]" # Or any other choice of the above

Two of those descriptions are worth reading closely. `[text]` is what installs Grounding DINO for SAMGeo 1 and 2 with text prompts. `[fer]` is described as installing the dependencies to run the feature edge reconstruction algorithm, and in the project file that extra is the core set plus GDAL.

The conda route splits the same dependency differently. Optional dependencies are left out of the default environment and need a second command:

conda install -c conda-forge groundingdino-py segment-anything-fast

So on pip, text prompts cost an extra. On conda, they cost a second command the reader has to know to run.

The SAMGeo 3 extra pulls a platform-specific compiler wheel

The lightest paths add a few packages to the core set. `samgeo` adds huggingface_hub. `fast` adds segment-anything-fast and sam2. `hq` adds segment_anything_hq, sam2 and timm.

`samgeo3` is a different shape of dependency set. Alongside the core packages it asks for sam3 at 0.1.4 or newer, scikit-learn, scikit-image, transformers, buildingregulariser, leafmap, localtileserver and spacy, and then two mutually exclusive entries: triton at 3.5.1 or newer when the platform is Linux, and triton-windows at 3.3.0.post19 or newer when it is Windows.

That is the practical difference between installing one model and installing another. SAM 3 pulls a transformer stack, a natural language library, a tile server and a compiler-grade dependency resolved per operating system, while the other extras stay inside the Python ecosystem. On a machine where the Triton wheel does not exist for your Python version, that single extra is where an install fails.

The Docker image installs the package twice and pins only the first

The Dockerfile starts from `jupyter/base-notebook:latest`, a floating tag, switches to root to install libgl1 and sqlite3, then drops to a numeric user and runs a mamba install of leafmap, localtileserver, segment-geospatial and `sam2==0.4.1`.

The next line is `pip install -U segment-geospatial jupyter-server-proxy`, which upgrades over whatever conda just resolved. The pip step upgrades segment-geospatial over the version the mamba step installed.

The rest of the image configures itself for notebooks rather than for a library. It enables the jupyter server proxy extension, sets PROJ_LIB to a path inside the image's conda prefix, exposes a build argument for the tile server's client prefix defaulting to `proxy/{port}`, fixes permissions on the conda directory, and copies the documentation examples into the image. The result is a runnable notebook environment, not a deployable service, even though the REST API extra exists.

The QGIS plugin lives in this tree and in its own repository

The QGIS Plugin section points at a separate project, opengeos/qgis-samgeo-plugin, and offers a short demo video and a full tutorial for using it.

The repository entries for this project also contain a `qgis-samgeo-plugin/` directory. So the plugin exists in two places, one of them a directory inside this repository.

An agent harness, a paper directory and four requirement files sit unmentioned

The top-level entries include an `agent-harness/` directory, a `paper/` directory, `package_plugin.py`, `zensical.toml`, `MANIFEST.in`, a `.pre-commit-config.yaml`, a `CITATION.cff`, and separate `requirements_dev.txt` and `requirements_docs.txt` files next to the base one.

The README also has a section headed Install SAM 3 on Windows, whose first line says it is a bit tricky.

Editorial conclusion

SamGeo is a well-documented wrapper with a packaging story that has grown faster than its metadata. Use it when you need SAM, HQ-SAM, Fast SAM or text-prompted segmentation over GeoTIFF data and you can live with picking one extra. Before you pin anything, read pyproject.toml rather than requirements.txt, since the two lists do not match, and check whether your platform is one where the samgeo3 extra needs a Triton build. Treat the Pre-Alpha classifier as the maintainers' own warning, and expect the recommended pixi path to need an edit to pixi.toml that the snippet itself defers to the docs.

Frequently asked questions

Official sources

1. License: MIT
2. opengeos/segment-geospatial on GitHub
3. Project website
4. README
5. Releases