viseron's setup script says 0.0.0 and its release says 3.7.0

The packaging version is 0.0.0 against a 3.7.0 release

`setup.py` is nine lines and most of them are placeholders.

setup(
    name="viseron",
    version="0.0.0",
    description="Viseron - Self-hosted, local only NVR with object detection",
    license="MIT",
    long_description=long_description,
    author="roflcoopter",
    url="https://github.com/roflcoopter/viseron",
    packages=["viseron"],
)

The version is the string `0.0.0`, which is what a template ships with, while the newest release is v3.7.0 and the two before it are 3.6.2 and 3.6.1. There is also no `console_scripts` entry, so nothing installs a command; the application is started from a single script, `manager.py`, at the root of the tree. And `packages` is a hand written list containing one name rather than a `find_packages()` call, so the subpackages under `viseron/` are not enumerated by the packaging metadata at all. For a project whose running surface is a Docker container, this file is close to vestigial, which is worth knowing before you try to `pip install` it.

Six requirements files and every pin written with equals

The tree carries six dependency files: `requirements.txt`, `requirements-3.9.txt`, `requirements_ci.txt`, `requirements_test.txt`, `requirements_container_test.txt` and `requirements_conflicts.txt`. The separate 3.9 file tells you Python 3.9 is still supported, which is notable because the lint configuration targets a later version, with `target-version = "py310"` under `[tool.ruff]`. Inside `requirements.txt` every one of the 46 entries is pinned with `==`, none with a range, down to `urllib3==2.8.0` and `setproctitle==1.3.7`. A fresh install therefore reproduces one machine's resolution rather than resolving anything, and there is no upper bound anywhere to stop a transitive dependency from moving under you.

Two aarch64 pins exist because of a Jetson Nano

The two comments in the dependency file explain more about the deployment target than any documentation would.

av==14.2.0; platform_machine == "aarch64" # Newer versions are incompatible with the Jetson Nano (Ubuntu bionic, glibc 2.27)

PyGObject==3.42.2 # Newer versions does not compile for the Jetson Nano

So the aarch64 path is pinned to an older glibc to match Ubuntu bionic on a Jetson Nano, and the two pins fail differently: one is a runtime incompatibility and one is a build failure. Both of them have a Python GObject binding in common, which is what makes an OS-level library a version constraint at all. This is the clearest statement on the project about what it is actually run on.

Object detection is installed by architecture, not by feature

Two of the detection packages are gated.

fast-alpr[onnx]==0.4.0; platform_machine == "x86_64" or platform_machine == "aarch64"

ultralytics==8.4.134; platform_machine == "x86_64" or platform_machine == "aarch64"

Both markers exclude every other `platform_machine`, so on anything that is not x86_64 or aarch64 those two never install and the detection features the description leads with are absent rather than degraded. Around them the unconditional list includes `face-recognition==1.3.0`, `dlib==20.0.1`, `supervision==0.30.1`, `deepstack-python==0.9` and `codeproject-ai-api==0.1`, plus `scikit-learn`, `scipy` and `numpy==1.26.4`. So the architecture gate applies to the detection stack rather than to the recorder, and the face recognition half of the feature list is installed everywhere.

Three recent releases titled after their own fixes

The release titles are changelog lines rather than version names. v3.6.1 is titled 3.6.1 with an FFmpeg drawtext filter fix, v3.6.2 is titled as a hotfix for recordings not loading, and v3.7.0 is titled with ONVIF support. Two of the last three releases are fixes, eleven days apart. The FFmpeg one is worth pausing on: ffmpeg appears nowhere in the Python dependency list, because it is a system binary supplied by the container image, so that fix landed in something the requirements file cannot tell you about. ONVIF support has a Python counterpart, `onvif-python==0.2.11`, which is the newest feature in the project and is pinned to a zero major version.

Ruff selects rule groups for Airflow, Django and pandas

The lint configuration is unusually long and mostly not about this project. Roughly forty-five rule groups are selected, and among them `AIR` for Airflow, `DJ` for Django, `PD` for pandas-vet, `NPY` for NumPy, `FAST` for FastAPI and `ERA` for eradicate. Viseron is an NVR application, not a data pipeline, so several of those groups are carried over from a template. The settings that do apply are `line-length = 88` and a `src` list of `viseron`, `tests` and `scripts`, with an `include` that adds `manager.py`. That include list is what leaves `setup.py` and anything under `config/` outside linting. Three more analysers are configured beside ruff as well, with `.flake8`, `.pylintrc` and `.mypy.ini` at the root, so four separate checkers run over one codebase.

The default branch is dev and the docs are deployed to Netlify

A clone gets the development branch, since the default is dev rather than master or main. The documentation the page sends you to lives at `viseron.netlify.app`, backed by a `netlify.toml` at the root, even though a `docs/` directory is also in the tree, so the prose exists in two places and the page points at the deployed one. Continuous integration is Azure Pipelines, with an `azure-pipelines/` directory and a `codecov.yaml` for coverage. The container image is assembled from checked-in material rather than written in a Dockerfile alone: there is a `rootfs/` directory alongside `docker/` and a `.dockerignore`, which is how the system libraries the Python pins complain about get into the image.

The page is 240 words and holds no install command

There is no image name, no port, no volume path and no compose file anywhere on it. The whole of the getting started section is that getting started is easy, you spin up a Docker container, you edit the configuration file with the built in web interface, and then you follow the instructions in the documentation. Everything else on the page is a pointer: a Component Explorer for browsing what exists, a Discord server that is described as the best place to get help with configuration and troubleshooting, and a request to open an issue instead of asking there if you have a confirmed bug. So the project's front door is a documentation site, and the repository is where you go after something has already gone wrong.

Editorial conclusion

Viseron is worth a look if you want camera footage and detection to stay on your own hardware, since that is the architectural claim the project leads with and the dependency list backs with no cloud client in it. Two things to check before committing hardware. Object detection is installed by architecture, gated on x86_64 or aarch64, so on anything else you get a recorder and no detector. And the packaging metadata is stale in a way that will confuse tooling, with a version of 0.0.0 and a single hardcoded package list, so install from the container image rather than from the source distribution.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. roflcoopter/viseron on GitHub