Align pricing terminology: pixels_per_unit -> pricing_unit_size (track go-livepeer #3942)
Nobody has claimed this yet.
Assessment
- Difficulty
- 1/5
- Estimated time
- Under an hour
- Newbie friendliness
- 68/100
Research direction
Start with examples/get_orchestrator_info.py and inspect how info.price_info.pixelsPerUnit is read. Rename the user-facing JSON key and pixel wording to pricing_unit_size and work units, while leaving src/livepeer_gateway/lp_rpc_pb2.py unchanged; done means the example uses the new terminology without changing the wire field.
Written by the indexing model from the issue text.
Description
Summary
Align the SDK's user-facing pricing terminology with go-livepeer, which is renaming the -pixelsPerUnit flag to -pricingUnitSize (see livepeer/go-livepeer#3942).
Background
pixelsPerUnit is really just a pricing scale factor: it is the number of work units that one quoted price covers, so price_per_work_unit = pricePerUnit / pixelsPerUnit. The "pixels" name is transcoding-era legacy and is confusing for non-video / BYOC / general-runner workloads, where there are no pixels.
go-livepeer#3942 introduces -pricingUnitSize as the primary flag and keeps -pixelsPerUnit as a deprecated alias. The wire/proto field (PriceInfo.pixelsPerUnit) is intentionally left unchanged for compatibility.
What to change in this SDK
User-facing terminology only — the generated proto field stays pixelsPerUnit:
examples/get_orchestrator_info.py- JSON dict key
pixels_per_unit->pricing_unit_size(snake_case analog ofpricingUnitSize). - Text output
... wei per N pixel(s)->... wei per N work unit(s). - Keep reading the wire field via
info.price_info.pixelsPerUnit.
- JSON dict key
Out of scope
src/livepeer_gateway/lp_rpc_pb2.pyis generated from the proto and carries the wire fieldpixelsPerUnit; do not hand-edit it.
Related
- go-livepeer#3942 (flag rename)
- In-flight PR #20 (
ja/live-runner) introduced a relatedunit_scaleconcept; it should adopt the samepricing_unit_sizename for consistency.
- Dominant language
- Python
- Stars
- 1
- Forks
- 7
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from livepeer/livepeer-python-gateway
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
livepeer/livepeer-python-gateway#64 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 1/5 Under an hour Newbie friendliness 70/100
livepeer/livepeer-python-gateway#12 · 1 comment ·
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
Difficulty 4/5 3-5 days Newbie friendliness 76/100
livepeer/livepeer-python-gateway#62 · 3 comments ·
All issues in livepeer/livepeer-python-gateway
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 91/100
TencentCloud/Octop#1577 · 1 comment ·
Maintainers usually reply within 1 day
-
bug frontend
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
PedestrianDynamics/pyFDS-Evac#552 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
resend/resend-skills#144 ·
Maintainers usually reply within 1 day
-
good first issue
Difficulty 1/5 Under an hour Newbie friendliness 68/100