Merge extensions into core package as PEP 771 extras

[seherv]

Description

Moves all the dapr-ext* packages into the main dapr package, and exposes them as extras.

pip install dapr-ext-pkgname is now pip install "dapr[pkgname]".

IMPORTANT: this is a breaking change, unlike the dapr*-dev removal. All the old extension packages must be uninstalled manually before re-installing dapr. More info in dapr/__init__.py, README.md and RELEASE.md.

Issue reference

We strive to have all PR being opened based on an issue, where the problem or feature have been discussed prior to implementation.

Please reference the issue this PR will close: #1026

Checklist

Please make sure you've completed the relevant tasks for this PR, out of the following list:

• Code compiles correctly
• Created/updated tests
• Extended the documentation

[codecov]

Codecov Report

❌ Patch coverage is 77.92208% with 34 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.98%. Comparing base (bffb749) to head (c6e898b).
⚠️ Report is 144 commits behind head on main.

Files with missing lines	Patch %	Lines
dapr/__init__.py	81.81%	14 Missing ⚠️
dapr/ext/fastapi/__init__.py	42.85%	4 Missing ⚠️
dapr/ext/flask/__init__.py	42.85%	4 Missing ⚠️
dapr/ext/grpc/__init__.py	33.33%	4 Missing ⚠️
dapr/ext/langgraph/__init__.py	42.85%	4 Missing ⚠️
dapr/ext/strands/__init__.py	33.33%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1054      +/-   ##
==========================================
- Coverage   86.63%   81.98%   -4.66%     
==========================================
  Files          84      116      +32     
  Lines        4473     9462    +4989     
==========================================
+ Hits         3875     7757    +3882     
- Misses        598     1705    +1107     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[Copilot]

Pull request overview

Copilot reviewed 121 out of 201 changed files in this pull request and generated 3 comments.

Comments suppressed due to low confidence (2)

pyproject.toml:1

• The dependency was renamed from msgpack-python (legacy, last release 0.5.6, capped at <1.0.0 in the deleted ext/*/pyproject.toml) to msgpack with >=1.0,<2.0. These are distinct PyPI projects with different APIs — msgpack 1.x removed encoding=/use_bin_type defaults and changed Unpacker/packb keyword arguments. Confirm that dapr/ext/langgraph/dapr_checkpointer.py and dapr/ext/strands/dapr_session_manager.py actually use the msgpack (1.x) API and not the msgpack-python (0.x) API; otherwise serialization of existing checkpoints/sessions in production state stores will break silently on upgrade.
  flask_dapr/init.py:1
• Importing actor and app as names from dapr.ext.flask only works if those submodules have already been bound as attributes of the parent package. dapr/ext/flask/__init__.py does from .actor import DaprActor / from .app import DaprApp, which sets the attributes as a side effect — but only when those imports succeed. If the optional flask dependency is missing, dapr.ext.flask.__init__ raises a new ImportError before binding actor/app, and this line will then raise ImportError: cannot import name 'actor' from 'dapr.ext.flask', masking the intended FutureWarning-then-helpful-error path. Consider importing the submodules explicitly (from dapr.ext.flask import actor, app on its own line, or import dapr.ext.flask.actor as actor) and/or wrapping in a try/except that surfaces the original cause.

[Copilot]

Pull request overview

Copilot reviewed 121 out of 201 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (1)

pyproject.toml:1

• all = ["dapr[fastapi,...]"] is a self-referential dependency (the project depending on itself with extras). Some resolvers/installers may reject this or behave unexpectedly (circular/recursive requirement). Prefer making all the explicit union of third-party deps (duplicating the lists), or use a build-tool-supported mechanism to compose extras without introducing a Requires-Dist: dapr[...] entry.

[Copilot]

Pull request overview

Copilot reviewed 122 out of 202 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (1)

pyproject.toml:1

• all is declared as an extra that depends on the same project (dapr[...]). Self-referential extras can confuse resolvers and may lead to circular/duplicate requirements (especially when users run pip install "dapr[all]"). Prefer expanding all to the union of the third-party dependencies across the other extras (duplicate the dependency strings), so all is just a normal list of external requirements.

[sicoyle]

few comments/questions. Overall, I am on a call with Cassie right now, bc we're supposed to release 1.18 today... so all of your 1.XX refs need to bump by one pls bc this will not make the 1.18 release.

[sicoyle]

do you do this on all of these pkgs we're changing?

[seherv]

Nope, just flask_dapr which is the only oddly named extension we have.

It was imported with import flask_dapr but all other extensions were imported as import dapr.ext.fastapi and I made this one consistent with that. This is a compatibility shim that actually installs dapr[flask] on a pip install flask_dapr==1.19 and it will only exist for one version. The forced re-export there is to keep it working until we finally deprecate it

[sicoyle]

this just means linter/type issues that need fixing? can you create an issue for this pls and link

[sicoyle]

can you actually update this to be 1.21. I just got on a call with cassie that we are cutting 1.18 today so 1.18 will not get these changes. This will be in for 1.19 so all of your 1.20 refs need to be 1.21 pls and any other 1.19 refs become 1.20 pls

[seherv]

Hmm, the way I see this:

• 1.18: released already, only dapr-ext-fastapi
• 1.19.dev: this branch merged into main, has dapr-ext-fastapi and dapr[fastapi] coexisting
• 1.19: same, dapr-ext-fastapi and dapr[fastapi]. Users have this version's lifetime to start switching
• 1.20: only dapr[fastapi], the old ext package not released at all

So I wouldn't bump any versions in the files, unless I am off by one, but I started from the fact that dapr-ext-fastapi==1.18.0 exists today and that one version is enough time for users to update

[sicoyle]

i see. @CasperGN and @acroca are y'all ok with this? If so, we can merge, and whoever is online first can have the honor 😁

[acroca]

Agree with Sam, but I even think we need to bump it to 1.22. We support N-2 versions, so by the time 1.18 become unsupported we will be releasing 1.21. Up to that point, users might still be in 1.18, and only then, they will be 'forced' to update to 1.21. So worst case scenario, users migrate from 1.18 to 1.21 because 1.18 is unsupported. So I think we should assist this migration by keeping the legacy check until 1.21, and remove it in 1.22.

Does this make sense?

Also I think we can stop publishing individual ext packages in 1.19. Users installing 1.19 from scratch don't need it, and users migrating to 1.19 will get the warning. In neither case we need the ext package shipped in 1.19, am I right?

[sicoyle]

thank you!