Suriyakumarvijayanayagam
b296e8a74a
Asked after the mobile-internet question: could a VPN let the office cameras
be shown in the demo. Three jobs get confused there and only one needs one.
Seeing the estate from anywhere already works and needs nothing - viewer mode
plus LiveHub is exactly that, outbound, no installation and no credential.
Demonstrating recognition is better done on the demo machine's own camera.
`webcam: 0` picks a capture index instead of building an RTSP URL and the
engine has supported it since the first version: CameraStore round-trips it,
source() returns the index, safe_url() reports webcam:0, and
POST /api/cameras {"id":"laptop","webcam":0} has always worked. No screen
offered it - the same gap this repo already records for the customer record
and per-camera tuning. It is now an option in the make picker, and it is the
strongest demo available: real faces, in the room, depending on no network.
A demo pointed at a camera in another building depends on two internet
connections and a tunnel staying up while somebody is talking.
The address and the index are alternatives, not extras: source() takes the
webcam first, so a half-typed host left behind would make the saved camera
describe two things and use one. The scan, the path and the camera password
are hidden for a local camera because none of them mean anything.
A tunnel is still right for one case - running the engine on a remote machine
against the office's own cameras - and still wrong for the product: it is
per-site infrastructure on every shop PC, and it gives head office
network-level access into a customer's LAN, where today we can read a
camera's picture and nothing else.
Also: installing httpx took the suite from 239 passed to 271. The HTTP tests
importorskip it so a bare checkout runs, which means the number at the bottom
of a run is not the number of tests that exist. Added to the dev extra.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KGcjxF1cNLcuwc3DAPcnfj
45 lines
1.5 KiB
TOML
45 lines
1.5 KiB
TOML
[project]
|
|
name = "behavision"
|
|
dynamic = ["version"]
|
|
description = "Production face recognition over RTSP"
|
|
requires-python = ">=3.10"
|
|
dependencies = [
|
|
# See requirements.txt for why numpy is uncapped and opencv is not.
|
|
"numpy>=1.26,<3.0",
|
|
"opencv-python>=4.8.1,<5",
|
|
"onnxruntime>=1.16",
|
|
"fastapi>=0.110",
|
|
"uvicorn>=0.29",
|
|
"pydantic>=2.6",
|
|
"PyYAML>=6.0",
|
|
"python-dotenv>=1.0",
|
|
"faiss-cpu>=1.7.4",
|
|
"requests>=2.31",
|
|
# DPAPI for camera passwords at rest (behavision/cameras.py). Without it the
|
|
# store logs a warning and writes them in the clear - which is what every
|
|
# Windows install had been doing, since nothing pulled this in.
|
|
"pywin32>=306; sys_platform == 'win32'",
|
|
]
|
|
|
|
[project.optional-dependencies]
|
|
# httpx is test-only and never ships in the wheel. The HTTP tests begin with
|
|
# `pytest.importorskip("httpx")` so a bare checkout still runs - which is
|
|
# right, and has a cost worth knowing: without it the suite reports 239 passed
|
|
# and quietly SKIPS 32 API tests. `pip install -e .[dev]` is how to get them.
|
|
dev = ["pytest>=8.0", "httpx>=0.27"]
|
|
|
|
[tool.setuptools.packages.find]
|
|
include = ["behavision*"]
|
|
|
|
[tool.setuptools.package-data]
|
|
behavision = ["static/*"]
|
|
|
|
[tool.pytest.ini_options]
|
|
testpaths = ["tests"]
|
|
|
|
# One version for the package and the wheel. Two literals in two files is how
|
|
# they came to disagree (1.0.0 here, 1.1.0 there) and how neither tracked a
|
|
# release.
|
|
[tool.setuptools.dynamic]
|
|
version = {attr = "behavision.__version__"}
|