Hrmm, I think many users that need activity discovery are using their own decorators and capturing in a big list/dict. If we want to make activity discovery more explicit, we should also consider providing other definition information such as the name, whether they have disabled thread-raise on cancel, etc.

Also, many people use different activities in different workers in the same process, so not sure it makes sense to have a "provider" API as if there is only one worker and all activities will belong to it. Users need to individually choose which activities to give to which workers.

I could see maybe exposing the activity definition and could see maybe exposing a way to get all known definitions that provide a@activity.defn decorator, but in general different users combine/collect activities in different ways and I'm not sure we want a "blessed" one.

It covers my use cases and I am only one user. Is there any way that we can ask devs and get numbers from the community on if they want this MR or something like it?

Also not suggesting that this will work for all users, only some.

Unfortunately with our open source nature it is hard to gauge interest unless it is something that is a pain point for users. I do think we could consider exposing all activity definitions in a static/global way, though that's not the same thing as a list you may want to map to callables and then pass into a worker. We have not done this traditionally in any other SDK, instead relying on users to collect their activities in their preferred way (though we have integrated with things like Sprint Boot in Java).

You have a Slack temporal community with +7,500 members in the #python-sdk, channel, may I ask them there?