2023-08-31 19:06:48 -04:00
# Dev Setup
2024-08-26 13:34:29 +02:00
This document describes how to setup your environment with Python and uv,
2023-04-12 10:43:01 -07:00
if you're working on new features or a bug fix for Semantic Kernel, or simply
want to run the tests included.
2024-08-26 13:34:29 +02:00
## System setup
2023-04-12 10:43:01 -07:00
2024-08-26 13:34:29 +02:00
## If you're on WSL
Python: Introduce Pydantic settings (#6193)
### Motivation and Context
SK Python is tightly coupled to the use of a `.env` file to read all
secrets, keys, endpoints, and more. This doesn't scale well for users
who wish to be able to use environment variables with their SK
Applications. By introducing Pydantic Settings, it is possible to use
both environment variables as well as have a fall-back to a `.env` file
(via a `env_file_path` parameter), if desired.
By introducing Pydantic Settings, we are removing the requirement to
have to create Text/Embedding/Chat completion objects with an `api_key`
or other previously required information (in the case of
AzureChatCompletion that means an `endpoint`, an `api_key`, a
`deployment_name`, and an `api_version`). When the AI connector is
created, the Pydantic settings are loaded either via env vars or the
fall-back `.env` file, and that means the user can create a chat
completion object like:
```python
chat_completion = OpenAIChatCompletion(service_id="test")
```
or, to optionally override the `ai_model_id` env var:
```python
chat_completion = OpenAIChatCompletion(service_id="test", ai_model_id="gpt-4-1106")
```
Note: we have left the ability to specific an `api_key`/`org_id` for
`OpenAIChatCompletion` or a `deployment_name`, `endpoint`, `base_url`,
and `api_version` for `AzureChatCompletion` as before, but if your
settings are configured to use env vars/.env file then there is no need
to pass this information.
<!-- 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 use of Pydantic settings and removes the use of
the python-dotenv library.
- Closes #1779
- Updates notebooks, samples, code and tests to remove the explicit
config of api_key or other previous .env files values.
- Adds new unit test config using monkeypatch to simulate env variables
for testing
- All unit and integration tests passing
<!-- 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 :smile:
2024-05-16 07:44:40 -04:00
2024-08-26 13:34:29 +02:00
Check that you've cloned the repository to `~/workspace` or a similar folder.
Avoid `/mnt/c/` and prefer using your WSL user's home directory.
Python: Introduce Pydantic settings (#6193)
### Motivation and Context
SK Python is tightly coupled to the use of a `.env` file to read all
secrets, keys, endpoints, and more. This doesn't scale well for users
who wish to be able to use environment variables with their SK
Applications. By introducing Pydantic Settings, it is possible to use
both environment variables as well as have a fall-back to a `.env` file
(via a `env_file_path` parameter), if desired.
By introducing Pydantic Settings, we are removing the requirement to
have to create Text/Embedding/Chat completion objects with an `api_key`
or other previously required information (in the case of
AzureChatCompletion that means an `endpoint`, an `api_key`, a
`deployment_name`, and an `api_version`). When the AI connector is
created, the Pydantic settings are loaded either via env vars or the
fall-back `.env` file, and that means the user can create a chat
completion object like:
```python
chat_completion = OpenAIChatCompletion(service_id="test")
```
or, to optionally override the `ai_model_id` env var:
```python
chat_completion = OpenAIChatCompletion(service_id="test", ai_model_id="gpt-4-1106")
```
Note: we have left the ability to specific an `api_key`/`org_id` for
`OpenAIChatCompletion` or a `deployment_name`, `endpoint`, `base_url`,
and `api_version` for `AzureChatCompletion` as before, but if your
settings are configured to use env vars/.env file then there is no need
to pass this information.
<!-- 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 use of Pydantic settings and removes the use of
the python-dotenv library.
- Closes #1779
- Updates notebooks, samples, code and tests to remove the explicit
config of api_key or other previous .env files values.
- Adds new unit test config using monkeypatch to simulate env variables
for testing
- All unit and integration tests passing
<!-- 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 :smile:
2024-05-16 07:44:40 -04:00
2024-08-26 13:34:29 +02:00
Ensure you have the WSL extension for VSCode installed.
Python: Introduce Pydantic settings (#6193)
### Motivation and Context
SK Python is tightly coupled to the use of a `.env` file to read all
secrets, keys, endpoints, and more. This doesn't scale well for users
who wish to be able to use environment variables with their SK
Applications. By introducing Pydantic Settings, it is possible to use
both environment variables as well as have a fall-back to a `.env` file
(via a `env_file_path` parameter), if desired.
By introducing Pydantic Settings, we are removing the requirement to
have to create Text/Embedding/Chat completion objects with an `api_key`
or other previously required information (in the case of
AzureChatCompletion that means an `endpoint`, an `api_key`, a
`deployment_name`, and an `api_version`). When the AI connector is
created, the Pydantic settings are loaded either via env vars or the
fall-back `.env` file, and that means the user can create a chat
completion object like:
```python
chat_completion = OpenAIChatCompletion(service_id="test")
```
or, to optionally override the `ai_model_id` env var:
```python
chat_completion = OpenAIChatCompletion(service_id="test", ai_model_id="gpt-4-1106")
```
Note: we have left the ability to specific an `api_key`/`org_id` for
`OpenAIChatCompletion` or a `deployment_name`, `endpoint`, `base_url`,
and `api_version` for `AzureChatCompletion` as before, but if your
settings are configured to use env vars/.env file then there is no need
to pass this information.
<!-- 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 use of Pydantic settings and removes the use of
the python-dotenv library.
- Closes #1779
- Updates notebooks, samples, code and tests to remove the explicit
config of api_key or other previous .env files values.
- Adds new unit test config using monkeypatch to simulate env variables
for testing
- All unit and integration tests passing
<!-- 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 :smile:
2024-05-16 07:44:40 -04:00
2024-08-26 13:34:29 +02:00
## Using uv
2023-04-12 10:43:01 -07:00
2024-08-26 13:34:29 +02:00
uv allows us to use SK from the local files, without worrying about paths, as
if you had SK pip package installed.
2023-04-12 10:43:01 -07:00
2024-08-26 13:34:29 +02:00
To install SK and all the required tools in your system, first, navigate to the directory containing
this DEV_SETUP using your chosen shell.
2023-03-16 19:54:34 -07:00
2024-08-26 13:34:29 +02:00
### For windows (non-WSL)
2023-03-16 19:54:34 -07:00
2024-08-26 13:34:29 +02:00
Check the [uv documentation ](https://docs.astral.sh/uv/getting-started/installation/ ) for the installation instructions. At the time of writing this is the command to install uv:
2023-03-16 19:54:34 -07:00
2024-08-26 13:34:29 +02:00
``` powershell
powershell -c " irm https://astral.sh/uv/install.ps1 | iex "
2023-08-31 19:06:48 -04:00
```
2023-03-16 19:54:34 -07:00
2024-08-26 13:34:29 +02:00
You can then run the following commands manually:
``` powershell
# Install Python 3.10, 3.11, and 3.12
uv python install 3.10 3.11 3.12
# Create a virtual environment with Python 3.10 (you can change this to 3.11 or 3.12)
$PYTHON_VERSION = " 3.10 "
uv venv - -python $PYTHON_VERSION
# Install SK and all dependencies
uv sync - -all -extras - -dev
# Install pre-commit hooks
uv run pre-commit install -c python / . pre-commit -config . yaml
```
2023-03-16 19:54:34 -07:00
2024-08-26 13:34:29 +02:00
Or you can then either install [`make` ](https://gnuwin32.sourceforge.net/packages/make.htm ) and then follow the guide for Mac and Linux, or run the following commands, the commands are shown as bash but should work in powershell as well.
2023-03-16 19:54:34 -07:00
2024-08-26 13:34:29 +02:00
### For Mac and Linux (both native and WSL)
2023-03-16 19:54:34 -07:00
2024-08-26 13:34:29 +02:00
It is super simple to get started, run the following commands:
2023-03-16 19:54:34 -07:00
``` bash
2024-08-26 13:34:29 +02:00
make install
2023-03-16 19:54:34 -07:00
```
2024-08-26 13:34:29 +02:00
This will install uv, python, Semantic Kernel and all dependencies and the pre-commit config. It uses python 3.10 by default, if you want to change that set the `PYTHON_VERSION` environment variable to the desired version (currently supported are 3.10, 3.11, 3.12). For instance for 3.12"
2025-01-09 02:47:09 -08:00
2024-08-26 13:34:29 +02:00
``` bash
make install PYTHON_VERSION = 3.12
```
2023-03-16 19:54:34 -07:00
2024-08-26 13:34:29 +02:00
If you want to change python version (without installing uv, python and pre-commit), you can use the same parameter, but do:
2023-03-16 19:54:34 -07:00
2024-08-26 13:34:29 +02:00
``` bash
make install-sk PYTHON_VERSION = 3.12
```
2024-06-03 12:36:14 -04:00
2024-08-26 13:34:29 +02:00
ℹ ️ **Note ** : Running the install or install-sk command will wipe away your existing virtual environment and create a new one.
2024-06-03 12:36:14 -04:00
2024-08-26 13:34:29 +02:00
Alternatively you can run the VSCode task `Python: Install` to run the same command.
2024-06-03 12:36:14 -04:00
2024-08-26 13:34:29 +02:00
## VSCode Setup
2024-06-03 12:36:14 -04:00
2025-01-09 02:47:09 -08:00
Install the [Python extension ](https://marketplace.visualstudio.com/items?itemName=ms-python.python ) for VSCode.
2025-08-12 10:17:53 +01:00
Open the workspace in [VSCode ](https://code.visualstudio.com/docs/editing/workspaces/workspaces ).
2024-08-26 13:34:29 +02:00
> The workspace for python should be rooted in the `./python` folder.
2024-06-03 12:36:14 -04:00
2024-08-26 13:34:29 +02:00
Open any of the `.py` files in the project and run the `Python: Select Interpreter`
command from the command palette. Make sure the virtual env (default path is `.venv` ) created by
`uv` is selected.
2024-06-03 12:36:14 -04:00
2024-08-26 13:34:29 +02:00
If prompted, install `ruff` . (It should have been installed as part of `uv sync --dev` ).
2024-06-03 12:36:14 -04:00
2024-08-26 13:34:29 +02:00
You also need to install the `ruff` extension in VSCode so that auto-formatting uses the `ruff` formatter on save.
Read more about the extension [here ](https://github.com/astral-sh/ruff-vscode ).
2024-06-03 12:36:14 -04:00
2025-01-08 03:34:46 +09:00
### Configuring Unit Testing in VSCode
- We have removed the strict dependency on forcing `pytest` usage via the `.vscode/settings.json` file.
- Developers are free to set up unit tests using their preferred framework, whether it is `pytest` or `unittest` .
2025-01-09 02:47:09 -08:00
- If needed, adjust VSCode's local `settings.json` (accessed via the Command Palette(`Ctrl+Shift+P` ) and type `Preferences: Open User Settings (JSON)` ) to configure the test framework. For example:
2025-01-08 03:34:46 +09:00
```json
2025-01-09 02:47:09 -08:00
"python.testing.unittestEnabled": false,
"python.testing.pytestEnabled": true,
2025-01-08 03:34:46 +09:00
` ``
2025-01-09 02:47:09 -08:00
2025-01-08 03:34:46 +09:00
Or, for ` unittest`:
2025-01-09 02:47:09 -08:00
2025-01-08 03:34:46 +09:00
` ``json
2025-01-09 02:47:09 -08:00
"python.testing.unittestEnabled": true,
"python.testing.pytestEnabled": false,
` ``
2025-01-08 03:34:46 +09:00
2024-08-26 13:34:29 +02:00
## LLM setup
2024-06-03 12:36:14 -04:00
2024-08-26 13:34:29 +02:00
Make sure you have an
[OpenAI API Key](https://platform.openai.com) or
[Azure OpenAI service key](https://learn.microsoft.com/azure/cognitive-services/openai/quickstart?pivots=rest-api)
2024-06-03 12:36:14 -04:00
2024-08-26 13:34:29 +02:00
There are two methods to manage keys, secrets, and endpoints:
2023-03-16 19:54:34 -07:00
2024-08-26 13:34:29 +02:00
1. Store them in environment variables. SK Python leverages pydantic settings to load keys, secrets, and endpoints from the environment.
> When you are using VSCode and have the python extension setup, it automatically loads environment variables from a ` .env` file, so you don't have to manually set them in the terminal.
> During runtime on different platforms, environment settings set as part of the deployments should be used.
2024-04-04 15:41:27 +02:00
2024-08-26 13:34:29 +02:00
2. Store them in a separate ` .env` file, like ` dev.env`, you can then pass that name into the constructor for most services, to the ` env_file_path` parameter, see below.
> Do not store ` *.env` files in your repository, and make sure to add them to your ` .gitignore` file.
2023-03-16 19:54:34 -07:00
2024-08-26 13:34:29 +02:00
There are a lot of settings, for a more extensive list of settings, see [ALL_SETTINGS.md](./samples/concepts/setup/ALL_SETTINGS.md).
2023-05-05 20:35:13 -07:00
2024-08-26 13:34:29 +02:00
### Example for file-based setup with OpenAI Chat Completions
To configure a ` .env` file with just the keys needed for OpenAI Chat Completions, you can create a ` openai.env` (this name is just as an example, a single ` .env` with all required keys is more common) file in the root of the ` python` folder with the following content:
2024-04-04 15:41:27 +02:00
2024-08-26 13:34:29 +02:00
Content of ` openai.env`:
2025-01-09 02:47:09 -08:00
2024-08-26 13:34:29 +02:00
` ``env
OPENAI_API_KEY=""
OPENAI_CHAT_MODEL_ID="gpt-4o-mini"
2023-04-12 10:43:01 -07:00
` ``
2023-03-16 19:54:34 -07:00
2024-08-26 13:34:29 +02:00
You will then configure the ChatCompletion class with the keyword argument ` env_file_path`:
2024-06-18 04:52:02 -07:00
2024-08-26 13:34:29 +02:00
` ``python
chat_completion = OpenAIChatCompletion(service_id="test", env_file_path="openai.env")
` ``
2023-03-16 19:54:34 -07:00
2023-08-31 19:06:48 -04:00
## Tests
2023-03-16 19:54:34 -07:00
2023-05-01 16:16:36 -07:00
You can run the unit tests under the [tests/unit](tests/unit/) folder.
2023-04-12 10:43:01 -07:00
2023-08-31 19:06:48 -04:00
` ``bash
2024-08-26 13:34:29 +02:00
uv run pytest tests/unit
2023-08-31 19:06:48 -04:00
` ``
2023-05-01 16:16:36 -07:00
2024-04-04 15:41:27 +02:00
Alternatively, you can run them using VSCode Tasks. Open the command palette
(` Ctrl+Shift+P`) and type ` Tasks: Run Task`. Select ` Python: Tests - Unit` or ` Python: Tests - Code Coverage` from the list.
2023-05-01 16:16:36 -07:00
You can run the integration tests under the [tests/integration](tests/integration/) folder.
2023-08-31 19:06:48 -04:00
` ``bash
2024-08-26 13:34:29 +02:00
uv run pytest tests/integration
2023-08-31 19:06:48 -04:00
` ``
2023-04-12 10:43:01 -07:00
2023-05-03 17:05:01 -07:00
You can also run all the tests together under the [tests](tests/) folder.
2023-08-31 19:06:48 -04:00
` ``bash
2024-08-26 13:34:29 +02:00
uv run pytest tests
2023-08-31 19:06:48 -04:00
` ``
2023-05-03 17:05:01 -07:00
2024-04-04 15:41:27 +02:00
Alternatively, you can run them using VSCode Tasks. Open the command palette
(` Ctrl+Shift+P`) and type ` Tasks: Run Task`. Select ` Python: Tests - All` from the list.
2024-05-04 07:50:04 -04:00
## Implementation Decisions
2024-01-26 10:15:35 -07:00
### Asynchronous programming
2024-05-04 07:50:04 -04:00
It's important to note that most of this library is written with asynchronous in mind. The
developer should always assume everything is asynchronous. One can use the function signature
2024-01-26 10:15:35 -07:00
with either ` async def` or ` def` to understand if something is asynchronous or not.
2024-05-31 15:06:41 +02:00
### Documentation
Each file should have a single first line containing: # Copyright (c) Microsoft. All rights reserved.
We follow the [Google Docstring](https://github.com/google/styleguide/blob/gh-pages/pyguide.md#383-functions-and-methods) style guide for functions and methods.
They are currently not checked for private functions (functions starting with '_').
They should contain:
2025-01-09 02:47:09 -08:00
2024-05-31 15:06:41 +02:00
- Single line explaining what the function does, ending with a period.
- If necessary to further explain the logic a newline follows the first line and then the explanation is given.
- The following three sections are optional, and if used should be separated by a single empty line.
- Arguments are then specified after a header called ` Args:`, with each argument being specified in the following format:
2025-01-09 02:47:09 -08:00
- ` arg_name`: Explanation of the argument.
2024-05-31 15:06:41 +02:00
- if a longer explanation is needed for a argument, it should be placed on the next line, indented by 4 spaces.
2024-08-26 13:34:29 +02:00
- Type and default values do not have to be specified, they will be pulled from the definition.
2024-05-31 15:06:41 +02:00
- Returns are specified after a header called ` Returns:` or ` Yields:`, with the return type and explanation of the return value.
- Finally, a header for exceptions can be added, called ` Raises:`, with each exception being specified in the following format:
2025-01-09 02:47:09 -08:00
- ` ExceptionType`: Explanation of the exception.
- if a longer explanation is needed for a exception, it should be placed on the next line, indented by 4 spaces.
2024-05-31 15:06:41 +02:00
Putting them all together, gives you at minimum this:
` ``python
def equal(arg1: str, arg2: str) -> bool:
"""Compares two strings and returns True if they are the same."""
...
` ``
2025-01-09 02:47:09 -08:00
2024-05-31 15:06:41 +02:00
Or a complete version of this:
` ``python
def equal(arg1: str, arg2: str) -> bool:
"""Compares two strings and returns True if they are the same.
Here is extra explanation of the logic involved.
Args:
2024-08-26 13:34:29 +02:00
arg1: The first string to compare.
arg2: The second string to compare.
2024-05-31 15:06:41 +02:00
This string requires extra explanation.
Returns:
2024-08-26 13:34:29 +02:00
True if the strings are the same, False otherwise.
2024-05-31 15:06:41 +02:00
Raises:
ValueError: If one of the strings is empty.
"""
...
` ``
If in doubt, use the link above to read much more considerations of what to do and when, or use common sense.
2023-08-04 12:04:56 -07:00
## Pydantic and Serialization
2023-08-09 15:29:56 +01:00
2023-08-04 12:04:56 -07:00
This section describes how one can enable serialization for their class using Pydantic.
2024-08-26 13:34:29 +02:00
For more info you can refer to the [Pydantic Documentation](https://docs.pydantic.dev/latest/).
2023-08-04 12:04:56 -07:00
### Upgrading existing classes to use Pydantic
Let's take the following example:
` ``python
class A:
def __init__(self, a: int, b: float, c: List[float], d: dict[str, tuple[float, str]] = {}):
self.a = a
self.b = b
self.c = c
self.d = d
` ``
2024-08-26 13:34:29 +02:00
You would convert this to a Pydantic class by sub-classing from the ` KernelBaseModel` class.
2023-08-04 12:04:56 -07:00
` ``python
from pydantic import Field
2024-01-24 08:51:56 -07:00
from semantic_kernel.kernel_pydantic import KernelBaseModel
2023-08-04 12:04:56 -07:00
2024-01-24 08:51:56 -07:00
class A(KernelBaseModel):
2023-08-04 12:04:56 -07:00
# The notation for the fields is similar to dataclasses.
a: int
b: float
2024-04-04 15:41:27 +02:00
c: list[float]
2023-08-04 12:04:56 -07:00
# Only, instead of using dataclasses.field, you would use pydantic.Field
2024-04-04 15:41:27 +02:00
d: dict[str, tuple[float, str]] = Field(default_factory=dict)
2023-08-04 12:04:56 -07:00
` ``
#### Classes with data that need to be serialized, and some of them are Generic types
Let's take the following example:
` ``python
from typing import TypeVar
T1 = TypeVar("T1")
T2 = TypeVar("T2", bound=<some class>)
class A:
def __init__(a: int, b: T1, c: T2):
self.a = a
self.b = b
self.c = c
` ``
2024-01-24 08:51:56 -07:00
You can use the ` KernelBaseModel` to convert these to pydantic serializable classes.
2023-08-04 12:04:56 -07:00
` ``python
2024-08-26 13:34:29 +02:00
from typing import Generic, TypeVar
2023-08-04 12:04:56 -07:00
2024-01-24 08:51:56 -07:00
from semantic_kernel.kernel_pydantic import KernelBaseModel
2023-08-04 12:04:56 -07:00
2024-08-26 13:34:29 +02:00
T1 = TypeVar("T1")
T2 = TypeVar("T2", bound=<some class>)
2024-01-24 08:51:56 -07:00
class A(KernelBaseModel, Generic[T1, T2]):
2023-08-04 12:04:56 -07:00
# T1 and T2 must be specified in the Generic argument otherwise, pydantic will
# NOT be able to serialize this class
a: int
b: T1
c: T2
` ``
2024-08-26 13:34:29 +02:00
## Code quality checks
2023-04-12 10:43:01 -07:00
2024-08-26 13:34:29 +02:00
To run the same checks that run during a commit and the GitHub Action ` Python Code Quality Checks`, you can use this command, from the [python](../python) folder:
2023-04-12 10:43:01 -07:00
2023-08-31 19:06:48 -04:00
` ``bash
2024-08-26 13:34:29 +02:00
uv run pre-commit run -a
2023-08-31 19:06:48 -04:00
` ``
2024-04-04 15:41:27 +02:00
or use the following task (using ` Ctrl+Shift+P`):
2025-01-09 02:47:09 -08:00
2024-04-04 15:41:27 +02:00
- ` Python - Run Checks` to run the checks on the whole project.
- ` Python - Run Checks - Staged` to run the checks on the currently staged files only.
2024-08-26 13:34:29 +02:00
Ideally you should run these checks before committing any changes, when you install using the instructions above the pre-commit hooks should be installed already.
2024-04-04 15:41:27 +02:00
## Code Coverage
We try to maintain a high code coverage for the project. To run the code coverage on the unit tests, you can use the following command:
` ``bash
2024-08-26 13:34:29 +02:00
uv run pytest --cov=semantic_kernel --cov-report=term-missing:skip-covered tests/unit/
2024-04-04 15:41:27 +02:00
` ``
2025-01-09 02:47:09 -08:00
2024-04-04 15:41:27 +02:00
or use the following task (using ` Ctrl+Shift+P`):
2025-01-09 02:47:09 -08:00
2024-04-04 15:41:27 +02:00
- ` Python: Tests - Code Coverage` to run the code coverage on the whole project.
2024-08-26 13:34:29 +02:00
This will show you which files are not covered by the tests, including the specific lines not covered. Make sure to consider the untested lines from the code you are working on, but feel free to add other tests as well, that is always welcome!
2024-04-04 15:41:27 +02:00
## Catching up with the latest changes
2025-01-09 02:47:09 -08:00
2024-04-04 15:41:27 +02:00
There are many people committing to Semantic Kernel, so it is important to keep your local repository up to date. To do this, you can run the following commands:
` ``bash
git fetch upstream main
git rebase upstream/main
git push --force-with-lease
` ``
2025-01-09 02:47:09 -08:00
2024-04-04 15:41:27 +02:00
or:
` ``bash
git fetch upstream main
git merge upstream/main
git push
` ``
This is assuming the upstream branch refers to the main repository. If you have a different name for the upstream branch, you can replace ` upstream` with the name of your upstream branch.
After running the rebase command, you may need to resolve any conflicts that arise. If you are unsure how to resolve a conflict, please refer to the [GitHub's documentation on resolving conflicts ](https://docs.github.com/en/get-started/using-git/resolving-merge-conflicts-after-a-git-rebase ), or for [VSCode ](https://code.visualstudio.com/docs/sourcecontrol/overview#_merge-conflicts ).
