Suriyakumarvijayanayagam
8f07dee048
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
19 lines
946 B
Python
19 lines
946 B
Python
"""Behavision — production face recognition over RTSP.
|
|
|
|
Pipeline: capture -> detect (YuNet) -> track (IoU) -> align + encode
|
|
(ArcFace ONNX) -> match / auto-enroll (FAISS + SQLite) -> events + API.
|
|
"""
|
|
|
|
# Stamped by release.sh from the git tag, into a copy of this line, so a
|
|
# release always produces a wheel nobody has installed before. It was a frozen
|
|
# "1.0.0" here and a frozen "1.1.0" in pyproject.toml - two literals that
|
|
# disagreed with each other and tracked nothing - which is how every engine fix
|
|
# for several releases silently failed to reach a machine that had run setup
|
|
# once. pip skips a wheel whose version is already installed and says so, one
|
|
# line above setup printing "[ok] Engine and dependencies installed".
|
|
#
|
|
# In a checkout it stays obviously a checkout: "0.0.0+dev" on /api/health is
|
|
# the truth about a developer's machine, and a plausible-looking number there
|
|
# would be worse than none.
|
|
__version__ = "0.0.0+dev"
|