Problem
Every package in this repo has a setup.py that renames the published package at build time:
dapr → dapr-dev
dapr-ext-grpc → dapr-ext-grpc-dev
- etc.
This runs on every push to main, publishing dev snapshots under separate PyPI package names. Extensions also swap their dapr dependency to dapr-dev in the same step.
This creates ongoing maintenance burden:
- Any new package needs this same boilerplate
setup.py
- It's the only reason
setup.py still exists — blocking a full migration to uv build/uv publish
- The logic is easy to get wrong (the workflow/strands extensions had it missing at one point)
Why it's no longer needed
Python packaging already solves this natively. PEP 440 dev releases (1.17.0.devN) are excluded from the default resolver. pip install dapr will never install a .dev version — users would need to explicitly pass --pre or pin the exact version. This has been the case since pip 9 (2016).
Our version strings already follow the PEP 440 .devN format. We're just not taking advantage of it.
Questions
- Are there any consumers of the
dapr-dev / *-dev packages on PyPI?
- Any concern about dev releases appearing alongside stable releases on the
dapr PyPI page? Potentially very noisy
- the
pip install --pre will now install .dev packages and not just release candidates. Acceptable?
Problem
Every package in this repo has a
setup.pythat renames the published package at build time:dapr→dapr-devdapr-ext-grpc→dapr-ext-grpc-devThis runs on every push to main, publishing dev snapshots under separate PyPI package names. Extensions also swap their
daprdependency todapr-devin the same step.This creates ongoing maintenance burden:
setup.pysetup.pystill exists — blocking a full migration touv build/uv publishWhy it's no longer needed
Python packaging already solves this natively. PEP 440 dev releases (
1.17.0.devN) are excluded from the default resolver.pip install daprwill never install a.devversion — users would need to explicitly pass--preor pin the exact version. This has been the case since pip 9 (2016).Our version strings already follow the PEP 440
.devNformat. We're just not taking advantage of it.Questions
dapr-dev/*-devpackages on PyPI?daprPyPI page? Potentially very noisypip install --prewill now install.devpackages and not just release candidates. Acceptable?