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 :smile:
2024-10-24 13:37:45 -04:00
|
|
|
# Copyright (c) Microsoft. All rights reserved.
|
|
|
|
|
|
2024-11-15 09:43:15 -05:00
|
|
|
from enum import Enum
|
|
|
|
|
|
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 :smile:
2024-10-24 13:37:45 -04:00
|
|
|
from semantic_kernel.kernel_pydantic import KernelBaseModel
|
|
|
|
|
from semantic_kernel.processes.kernel_process.kernel_process_function_target import KernelProcessFunctionTarget
|
|
|
|
|
from semantic_kernel.processes.process_end_step import EndStep
|
|
|
|
|
from semantic_kernel.processes.process_step_builder import ProcessStepBuilder
|
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 :smile:
2025-02-27 09:17:54 +09:00
|
|
|
from semantic_kernel.utils.feature_stage_decorator import experimental
|
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 :smile:
2024-10-24 13:37:45 -04:00
|
|
|
|
|
|
|
|
|
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 :smile:
2025-02-27 09:17:54 +09:00
|
|
|
@experimental
|
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 :smile:
2024-10-24 13:37:45 -04:00
|
|
|
class ProcessFunctionTargetBuilder(KernelBaseModel):
|
|
|
|
|
"""A builder for a process function target."""
|
|
|
|
|
|
|
|
|
|
step: ProcessStepBuilder
|
|
|
|
|
function_name: str | None = None
|
|
|
|
|
parameter_name: str | None = None
|
|
|
|
|
target_event_id: str | None = None
|
|
|
|
|
|
2024-11-15 09:43:15 -05:00
|
|
|
def __init__(
|
|
|
|
|
self, step: ProcessStepBuilder, function_name: str | Enum | None = None, parameter_name: str | None = None
|
|
|
|
|
):
|
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 :smile:
2024-10-24 13:37:45 -04:00
|
|
|
"""Initializes a new instance of ProcessFunctionTargetBuilder."""
|
|
|
|
|
from semantic_kernel.functions.kernel_function_metadata import KernelFunctionMetadata # noqa: F401
|
|
|
|
|
|
|
|
|
|
ProcessFunctionTargetBuilder.model_rebuild()
|
|
|
|
|
|
2024-11-15 09:43:15 -05:00
|
|
|
function_name_str: str | None = function_name.value if isinstance(function_name, Enum) else function_name
|
|
|
|
|
|
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 :smile:
2024-10-24 13:37:45 -04:00
|
|
|
if isinstance(step, EndStep):
|
2024-11-15 09:43:15 -05:00
|
|
|
function_name_str = "END"
|
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 :smile:
2024-10-24 13:37:45 -04:00
|
|
|
parameter_name = None
|
|
|
|
|
else:
|
2024-11-15 09:43:15 -05:00
|
|
|
target = step.resolve_function_target(function_name_str, parameter_name)
|
|
|
|
|
function_name_str = target.function_name
|
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 :smile:
2024-10-24 13:37:45 -04:00
|
|
|
parameter_name = target.parameter_name
|
|
|
|
|
|
2024-11-15 09:43:15 -05:00
|
|
|
super().__init__(step=step, function_name=function_name_str, parameter_name=parameter_name)
|
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 :smile:
2024-10-24 13:37:45 -04:00
|
|
|
|
|
|
|
|
def build(self) -> KernelProcessFunctionTarget:
|
|
|
|
|
"""Builds the KernelProcessFunctionTarget."""
|
|
|
|
|
if not self.step.id:
|
|
|
|
|
raise ValueError("Step ID cannot be None")
|
|
|
|
|
|
|
|
|
|
return KernelProcessFunctionTarget(
|
|
|
|
|
step_id=self.step.id,
|
|
|
|
|
function_name=self.function_name,
|
|
|
|
|
parameter_name=self.parameter_name,
|
|
|
|
|
target_event_id=self.target_event_id,
|
|
|
|
|
)
|
