Skip to content

feat(weights): record kg or lb, and RiR targets on planned sets - #6

Open
wromansky wants to merge 2 commits into
wger-project:masterfrom
wromansky:feat/weight-units-and-rir
Open

feat(weights): record kg or lb, and RiR targets on planned sets#6
wromansky wants to merge 2 commits into
wger-project:masterfrom
wromansky:feat/weight-units-and-rir

Conversation

@wromansky

Copy link
Copy Markdown
Contributor

Three related gaps, all found coaching a real trainee through this server against a self-hosted wger.

1. Everything was kilograms

log_set took weight_kg and never sent weight_unit, so a trainee who trains in pounds had their working weights converted on the way in and back on the way out — 225 lb stored as 102.06 kg — even with their wger profile set to lb. wger models the unit explicitly (/api/v2/setting-weightunit/: 1 = kg, 2 = lb), so there is no reason to flatten it.

log_set, update_workout_log and add_exercise_with_sets now take weight_unit ('kg' or 'lb', default kg), and the number is stored in the unit it was given in.

The parameter is renamed weight_kgweight, because the name was the bug.

Note the unit lives in two different places in wger, which is easy to miss: a workout log carries its own weight_unit, while a planned set takes it from its slot entry. add_exercise_with_sets sets it on the entry it creates.

2. set_slot_entry_config could not say what a weight meant

Same root cause, worse failure. Setting a planned weight through that tool wrote only the config, leaving the number interpreted in whatever unit the entry already carried.

Observed end to end: an assistant was asked to set a trainee's working weights in pounds, wrote 175 / 50 / 35 / 25 / 40 to five weight configs, and every one landed as kilograms. The plan then read a 175 kg incline barbell press — 386 lb — for five reps. Nothing errored, and the tool's response looked correct.

kind='weight' (and 'max_weight') now accepts weight_unit and patches the entry before writing the config, so one call leaves a coherent record. Passing it with any other kind is refused rather than ignored.

3. A planned set could not carry a RiR target

wger has rir-config for exactly this and the tool ignored it, so autoregulated programming — "3 × 8 leaving 2 in reserve" — could not be expressed in a plan at all, only logged after the fact. add_exercise_with_sets now takes an optional rir.

Related: weight on a planned set is now optional. A coach writing a program for someone whose strength is unknown had to invent a number; omit it and prescribe sets, reps and RiR instead, and let the load be filled in from the first session.

Tests

10 new tests in tests/test_weight_units_and_rir.py: pounds stay pounds, kg remains the default, an unknown unit is refused, a reps-only update leaves the recorded unit untouched, a planned set records both unit and RiR, weight may be omitted, rir stays optional, the unit reaches the entry while the value reaches the config, a unit on a non-weight kind is refused without touching either endpoint, and omitting it leaves the entry alone.

Full suite passes (81) and ruff check is clean.

Note

Touches log_set alongside #3, which extends the same function with routine linkage — they merge cleanly in either order, but whichever lands second will want a trivial rebase. Independent of #2, #4 and #5.

wromansky and others added 2 commits August 12, 2026 21:46
Three related gaps, all found coaching a real trainee through this server.

**Everything was kilograms.** log_set took weight_kg and never sent
weight_unit, so a trainee who trains in pounds got their working weights
converted on the way in and converted back on the way out — 225 lb stored as
102.06 kg — even when their wger profile is set to lb. wger models the unit
explicitly (/api/v2/setting-weightunit/: 1 = kg, 2 = lb), so there is no
reason to flatten it.

log_set, update_workout_log and add_exercise_with_sets now take
weight_unit ('kg' or 'lb'), defaulting to kg, and the weight is stored in the
unit it was given in. The parameter is renamed weight_kg -> weight, since the
name was the bug. Note the unit lives in two different places in wger: a
workout log carries its own weight_unit, while a planned set takes it from its
slot entry — add_exercise_with_sets sets it on the entry it creates.

**A planned set could not carry a RiR target.** wger has rir-config for
exactly this and the tool ignored it, so autoregulated programming — "3 x 8
leaving 2 in reserve" — could not be expressed at all, only logged after the
fact. add_exercise_with_sets now takes an optional rir.

**weight was mandatory on a planned set.** A coach writing a program for
someone whose strength is unknown had to invent a number. It is now optional:
omit it to prescribe sets, reps and RiR and let the load be filled in from the
first session.

Adds 7 tests: pounds stay pounds, kg remains the default, an unknown unit is
refused, a reps-only update leaves the unit untouched, a planned set records
both unit and RiR, weight may be omitted, and rir stays optional.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Setting a planned weight through set_slot_entry_config had no way to say what
the number meant. wger keeps the unit on the slot ENTRY, not on the weight
config, so a weight written here is silently interpreted in whatever unit the
entry already carried — kg by default.

Observed end to end: an assistant was asked to set a trainee's working weights
in pounds, wrote 175 / 50 / 35 / 25 / 40 to five weight configs, and every one
of them landed as kilograms. The plan then read a 175 kg incline barbell press
— 386 lb — for five reps. Nothing errored, and the number looked right in the
tool's own response.

kind='weight' (or 'max_weight') now accepts weight_unit and patches the entry
before writing the config, so one call leaves a coherent record. Passing it
with any other kind is refused rather than ignored.

Adds 3 tests: the unit reaches the entry while the value reaches the config, a
unit on a non-weight kind is refused without touching either endpoint, and
omitting it leaves the entry alone.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant