The SSL fix shipped and did not reach the machine it was written for. That log said so, one line above the tick: behavision is already installed with the same version as the provided wheel. Use --force-reinstall to force an installation of the wheel. [ok] Engine and dependencies installed and the traceback below it still pointed at model_assets.py line 59, urllib.request.urlretrieve - code the fix had deleted. Two frozen literals caused it: version = "1.1.0" in pyproject.toml and __version__ = "1.0.0" in behavision/__init__.py. They disagreed with each other and neither tracked a release, so every release built behavision-1.1.0-py3-none-any.whl and pip install --upgrade on a machine that already had 1.1.0 is a no-op. The comment beside that call claimed the opposite. The shape of the damage is what makes it bad. The Go binaries - app, agent, setup tool - are rebuilt every release and updated normally. So a shop PC ran a current app supervising an engine several releases old, and nothing said which: /api/health reported the model, the paths, the cameras and the gallery, and no version at all. - One version, in the package, read by pyproject through [tool.setuptools.dynamic]. In a checkout it reads 0.0.0+dev: a plausible-looking number on a developer's /api/health is worse than none. - pip install --force-reinstall --no-deps <wheel>, after the ordinary --upgrade. --upgrade settles the dependencies; the second call guarantees our own code is the code in the folder. --no-deps keeps it cheap - forcing the dependencies too would re-download ~300 MB every run. A rebuild at an unchanged version is the ordinary case while developing, so this must not rely on the version moving. - release.sh stamps the tag: v0.5.6-demo -> 0.5.6+demo, valid PEP 440. Into a copy of the line, reverted in a trap, so the tree is never left dirty. /api/health reports version now. Without it there is no way to tell a shop PC three releases behind from a current one, which is how this survived several releases. Reproduced end to end before fixing, against real wheels on Python 3.12: two builds of the same version, --upgrade leaves the old code in place and prints the same sentence the colleague's Mac printed, --force-reinstall --no-deps replaces it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KGcjxF1cNLcuwc3DAPcnfj
41 lines
1.2 KiB
TOML
41 lines
1.2 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]
|
|
dev = ["pytest>=8.0"]
|
|
|
|
[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__"}
|