mirror of
https://github.com/microsoft/semantic-kernel.git
synced 2026-10-12 11:19:56 +00:00
copilot/bump-messagepack-version
10
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Evan Mattson
|
30d2b0802a |
Python: Support Process State Management (#11637)
### Motivation and Context
SK Python processes have been missing support to be able to serialize
and deserialize JSON state for a process and its steps. This PR brings
in the functionality to allow the developer to do so. The
`getting_started_with_processes` step03 has been update to reflect this
latest functionality. It is possible to dump a JSON state to a file, and
reload the state to continue running the process.
State metadata that handles the version for steps is managed via a
decorator:
```python
@kernel_process_step_metadata("CutFoodStep.V1")
class CutFoodStep(KernelProcessStep):
class Functions(Enum):
ChopFood = "ChopFood"
SliceFood = "SliceFood"
```
If no decorator/state is supplied the step will be built with a default
state version of "v1" which aligns with .Net.
<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
1. Why is this change required?
2. What problem does it solve?
3. What scenario does it contribute to?
4. If it fixes an open issue, please link to the issue here.
-->
### Description
Support state and versioning management for Python processes.
- Update samples to reflect changes.
- Closes #9584
<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->
### Contribution Checklist
<!-- Before submitting this PR, please make sure: -->
- [X] The code builds clean without any errors or warnings
- [X] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [X] All unit tests pass, and I have added new tests where possible
- [ ] I didn't break anyone 😄
|
||
|
Evan Mattson
|
fb70825df7 |
Python: Improve handling the Dapr process context (#10725)
### Motivation and Context There is a bug in the current Dapr runtime code that prohibits trying to get the Dapr process context out from a process once it's finished. This is related to incorrect handling of serializing/deserializing the Dapr process context. Additionally, in a state that handles `KernelProcessStepState`, due to Dapr serialization constraints, the step step injected to a step is not the actual object. We use Pydantic's `model_validate` to get the actual step object, but and we need to make sure we re-assign that object back to the underlying step state so the objects don't diverge (`model_validate` creates a new object). <!-- Thank you for your contribution to the semantic-kernel repo! Please help reviewers and future users, providing the following information: 1. Why is this change required? 2. What problem does it solve? 3. What scenario does it contribute to? 4. If it fixes an open issue, please link to the issue here. --> ### Description Improve the handling for the Dapr process context so we're properly serializing data through the Dapr process. - Fixes the issue brought up in the discussion: #10234 <!-- Describe your changes, the overall approach, the underlying design. These notes will help understanding how your code works. Thanks! --> ### Contribution Checklist <!-- Before submitting this PR, please make sure: --> - [X] The code builds clean without any errors or warnings - [X] The PR follows the [SK Contribution Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md) and the [pre-submission formatting script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts) raises no violations - [X] All unit tests pass, and I have added new tests where possible - [X] I didn't break anyone 😄 |
||
|
Evan Mattson
|
174bdabf38 |
Python: Introduce feature decorator to allow for experimental and release candidate decorator usage (#10691)
### Motivation and Context
<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
1. Why is this change required?
2. What problem does it solve?
3. What scenario does it contribute to?
4. If it fixes an open issue, please link to the issue here.
-->
This change is required to improve the flexibility and maintainability
of our feature annotation system. Previously, separate decorators (e.g.,
`experimental_function` and `experimental_class`) were used to mark
experimental features, resulting in code duplication and limiting our
ability to handle additional feature stages. As our SDK evolves, we need
a unified approach that can support multiple stages—such as
experimental, release candidate, and future states—while also allowing
version information for release candidate features to be centrally
managed.
### Description
<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->
This PR refactors our feature decorators by introducing a unified
`stage` decorator that updates the docstring and attaches metadata for
both functions and classes. Two convenience decorators, `experimental`
and `release_candidate`, are built on top of `stage`:
- The `experimental` decorator marks features as experimental and sets
an `is_experimental` attribute.
- The `release_candidate` decorator supports multiple usage patterns
(with or without parentheses and with an optional version parameter) to
mark features as release candidate and sets an `is_release_candidate`
attribute.
This unified approach reduces duplication, simplifies the codebase, and
lays the groundwork for easily extending feature stages in the future.
This decorator supports the following usage patterns:
- `@experimental` (for both classes and functions)
- `@release_candidate` (no parentheses)
- `@release_candidate()` (empty parentheses)
- `@release_candidate("1.21.3-rc1")` (positional version)
- `@release_candidate(version="1.21.3-rc1")` (keyword version)
### Contribution Checklist
<!-- Before submitting this PR, please make sure: -->
- [X] The code builds clean without any errors or warnings
- [X] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [X] All unit tests pass, and I have added new tests where possible
- [X] I didn't break anyone 😄
|
||
|
K. Andrew Parker
|
d91c96d4e1 |
Python: resolving #10642 - public events fail to propagate (#10643)
### Motivation and Context Resolves #10642 -- failure of `KernelProcessEventVisibility.Public` events to propagate. ### Description First, `KernelProcessEvent` was configured to use enum values -- though throughout the code, `KernelProcessEvent.visibility` is compared as an enum. Second, when handling events emitted by a KernelProcessStep, any `Public` visibility events are/were passed through `LocalStep.scoped_event` (which modifies the event's namespace) *before* queueing up any matching edges on the source step. This change to the event namespace effectively prevents the event from propagating (since I don't know how we'd 'listen' for events on the local process handle from within the function that builds that very process...) Allowing `visibility` on `KernelProcessEvent` to be an enum, combined with an exchange in the order of processing event messages (matching event to edge _before_ re-emitting any events marked as 'Public') causes public events to propagate as expected. ### Contribution Checklist - [X] The code builds clean without any errors or warnings - [X] The PR follows the [SK Contribution Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md) and the [pre-submission formatting script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts) raises no violations - [X] All unit tests pass, and I have added new tests where possible - [X] I didn't break anyone 😄 |
||
|
Eduard van Valkenburg
|
7bdf55028c |
Python: experimental py3.13 support (#10276)
### Motivation and Context <!-- Thank you for your contribution to the semantic-kernel repo! Please help reviewers and future users, providing the following information: 1. Why is this change required? 2. What problem does it solve? 3. What scenario does it contribute to? 4. If it fixes an open issue, please link to the issue here. --> Some small fixes in uv setup within actions Added experimental unit tests runs for py3.13 First typing improvement from pyright and pyright config. ### Description <!-- Describe your changes, the overall approach, the underlying design. These notes will help understanding how your code works. Thanks! --> ### Contribution Checklist <!-- Before submitting this PR, please make sure: --> - [x] The code builds clean without any errors or warnings - [x] The PR follows the [SK Contribution Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md) and the [pre-submission formatting script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts) raises no violations - [x] All unit tests pass, and I have added new tests where possible - [x] I didn't break anyone 😄 |
||
|
Evan Mattson
|
8f4efa5d10 |
Python: Allow for factory callbacks in the process framework (#10451)
### Motivation and Context
In the current Python process framework, in runtimes like Dapr, there is
no easy way to pass complex (unserializable) dependencies to a step --
this includes things like a ChatCompletion service or an agent of type
ChatCompletionAgent.
Similar to how the kernel dependency was propagated to the step_actor or
process_actor, we're introducing the ability to specify a factory
callback that will be called as the step is instantiated. The factory is
created, if specified via the optional kwarg when adding a step to the
process builder like:
```python
myBStep = process.add_step(step_type=BStep, factory_function=bstep_factory)
```
The `bstep_factory` looks like (along with its corresponding step)
```python
async def bstep_factory():
"""Creates a BStep instance with ephemeral references like ChatCompletionAgent."""
kernel = Kernel()
kernel.add_service(AzureChatCompletion())
agent = ChatCompletionAgent(kernel=kernel, name="echo", instructions="repeat the input back")
step_instance = BStep()
step_instance.agent = agent
return step_instance
class BStep(KernelProcessStep):
"""A sample BStep that optionally holds a ChatCompletionAgent.
By design, the agent is ephemeral (not stored in state).
"""
# Ephemeral references won't be persisted to Dapr
# because we do not place them in a step state model.
# We'll set this in the factory function:
agent: ChatCompletionAgent | None = None
@kernel_function(name="do_it")
async def do_it(self, context: KernelProcessStepContext):
print("##### BStep ran (do_it).")
await asyncio.sleep(2)
if self.agent:
history = ChatHistory()
history.add_user_message("Hello from BStep!")
async for msg in self.agent.invoke(history):
print(f"BStep got agent response: {msg.content}")
await context.emit_event(process_event="BStepDone", data="I did B")
```
Although this isn't explicitly necessary with the local runtime, the
factory callback will also work, if desired.
<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
1. Why is this change required?
2. What problem does it solve?
3. What scenario does it contribute to?
4. If it fixes an open issue, please link to the issue here.
-->
### Description
Adds the ability to specify a factory callback for a step in the process
framework.
- Adjusts the Dapr FastAPI demo sample to show how one can include a
dependency like a `ChatCompletionAgent` and use the factory callback for
`BStep`. Although the output from the agent isn't needed, it
demonstrates the capability to handle these types of dependencies while
running Dapr.
- Adds unit tests
- Closes #10409
<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->
### Contribution Checklist
<!-- Before submitting this PR, please make sure: -->
- [X] The code builds clean without any errors or warnings
- [X] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [X] All unit tests pass, and I have added new tests where possible
- [X] I didn't break anyone 😄
|
||
|
Eduard van ValkenburgandEvan Mattson
|
dc7cb45ed6 |
Python: remove mistaken on_activate func (#9839)
### Motivation and Context <!-- Thank you for your contribution to the semantic-kernel repo! Please help reviewers and future users, providing the following information: 1. Why is this change required? 2. What problem does it solve? 3. What scenario does it contribute to? 4. If it fixes an open issue, please link to the issue here. --> Removes an outdated function `on_activate` from the KernelProcessStep class and the one place it was overridden. Fixes #9829 ### Description <!-- Describe your changes, the overall approach, the underlying design. These notes will help understanding how your code works. Thanks! --> ### Contribution Checklist <!-- Before submitting this PR, please make sure: --> - [x] The code builds clean without any errors or warnings - [x] The PR follows the [SK Contribution Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md) and the [pre-submission formatting script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts) raises no violations - [x] All unit tests pass, and I have added new tests where possible - [x] I didn't break anyone 😄 Co-authored-by: Evan Mattson <[email protected]> |
||
|
Evan Mattson
|
29e3e83c2d |
Python: Add the Dapr Runtime for Processes (#9642)
### Motivation and Context In addition to the Python local process runtime, we're adding the ability to congfigure the Dapr runtime for Python SK processes. <!-- Thank you for your contribution to the semantic-kernel repo! Please help reviewers and future users, providing the following information: 1. Why is this change required? 2. What problem does it solve? 3. What scenario does it contribute to? 4. If it fixes an open issue, please link to the issue here. --> ### Description The PR introduces: - The ability to configure the Dapr Runtime for Python processes - Adds a sample FastAPI app showing how to configure the Dapr runtime with a sample SK Python process (see the README for details on setup) - Adds some unit test coverage for the Dapr runtime - Closes #9355 <!-- Describe your changes, the overall approach, the underlying design. These notes will help understanding how your code works. Thanks! --> ### Contribution Checklist <!-- Before submitting this PR, please make sure: --> - [X] The code builds clean without any errors or warnings - [X] The PR follows the [SK Contribution Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md) and the [pre-submission formatting script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts) raises no violations - [X] All unit tests pass, and I have added new tests where possible - [X] I didn't break anyone 😄 |
||
|
Evan Mattson
|
6aa322975e |
Python: Add step03 getting started with processes samples. (#9427)
### Motivation and Context Add step03 getting started with processes samples to show how to create kernel processes related to food preparation and food ordering tasks. <!-- Thank you for your contribution to the semantic-kernel repo! Please help reviewers and future users, providing the following information: 1. Why is this change required? 2. What problem does it solve? 3. What scenario does it contribute to? 4. If it fixes an open issue, please link to the issue here. --> ### Description Add step03 getting started with processes samples. - Make `emit_event` async - Simplify how one can create an event to emit by allowing the process_event to be a string, along with kwargs: ``` await context.emit_event(process_event=CommonEvents.StartBRequested.value, data="Get Going B") ``` <!-- Describe your changes, the overall approach, the underlying design. These notes will help understanding how your code works. Thanks! --> ### Contribution Checklist <!-- Before submitting this PR, please make sure: --> - [X] The code builds clean without any errors or warnings - [X] The PR follows the [SK Contribution Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md) and the [pre-submission formatting script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts) raises no violations - [X] All unit tests pass, and I have added new tests where possible - [X] I didn't break anyone 😄 |
||
|
Evan Mattson
|
6eba848e91 |
Python: Add the Python process framework (#9363)
### Motivation and Context An initial PR to add the foundational pieces of the Python Process framework, which holds it design to be similar to dotnet in that step types are added to a process builder, and later on, when the step is run, it is first instantiated and the proper state is provided. <!-- Thank you for your contribution to the semantic-kernel repo! Please help reviewers and future users, providing the following information: 1. Why is this change required? 2. What problem does it solve? 3. What scenario does it contribute to? 4. If it fixes an open issue, please link to the issue here. --> ### Description Adding the initial process framework components: - Closes #9354 **TODO** - more unit tests will be added to increase the code coverage. Currently there are several files with no (or low) code coverage. - more samples will either be added to this PR or a subsequent PR <!-- Describe your changes, the overall approach, the underlying design. These notes will help understanding how your code works. Thanks! --> ### Contribution Checklist <!-- Before submitting this PR, please make sure: --> - [X] The code builds clean without any errors or warnings - [X] The PR follows the [SK Contribution Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md) and the [pre-submission formatting script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts) raises no violations - [X] All unit tests pass, and I have added new tests where possible - [X] I didn't break anyone 😄 |