pointguard 0.0.5
PointGuardAI tool for logging and evaluating LLM traces
License: Apache 2.0 License
Requires Python: >=3.10
Keywords: pointguard

# Pointguard Python SDK

[![PyPI version](https://img.shields.io/pypi/v/pointguard.svg)](https://pypi.org/project/pointguard/)
[![Python versions](https://img.shields.io/pypi/pyversions/pointguard.svg)](https://pypi.org/project/pointguard/)
[![Downloads](https://static.pepy.tech/badge/pointguard)](https://pepy.tech/project/pointguard)
[![License](https://img.shields.io/github/license/comet-ml/pointguard)](https://github.com/comet-ml/pointguard/blob/main/LICENSE)

The pointguard Python SDK allows you to integrate your Python applications with the pointguard platform, enabling comprehensive tracing, evaluation, and monitoring of your LLM systems. pointguard helps you build, evaluate, and optimize LLM systems that run better, faster, and cheaper.

Pointguard is an open-source LLM evaluation platform by [PointGuardAI](https://www.pointguardai.com). For more information about the broader pointguard ecosystem, visit our main [GitHub repository](https://github.com/comet-ml/pointguard), [Website](https://www.comet.com/site/products/pointguard/), or [Documentation](https://www.comet.com/docs/pointguard/).

## Quickstart

Get started quickly with pointguard using our interactive notebook:

## Installation

Install the `pointguard` package using pip or uv:

```bash
# using pip
pip install pointguard

# using uv (faster)
uv pip install pointguard
```

## Configuration

Configure the Python SDK by running the `pointguard configure` command. This will prompt you for your pointguard server address (for self-hosted instances) or your API key and workspace (for Comet.com):

```bash
pointguard configure
```

You can also configure the SDK programmatically in your Python code:
```python
import pointguard

# For Comet.com Cloud
pointguard.configure(
    api_key="YOUR_API_KEY",
    workspace="YOUR_WORKSPACE", # Usually found in your Comet URL: https://www.comet.com/YOUR_WORKSPACE/...
    project_name="optional-project-name" # Optional: set a default project for traces
)

# For self-hosted pointguard instances
# pointguard.configure(use_local=True, project_name="optional-project-name")
```
Refer to the [Python SDK documentation](https://www.comet.com/docs/pointguard/python-sdk-reference/) for more configuration options.

### Dynamic Tracing Control

Control tracing behavior at runtime without code changes:

```python
import pointguard

# Disable tracing globally
pointguard.set_tracing_active(False)

# Check current state
print(pointguard.is_tracing_active())  # False

# Re-enable tracing
pointguard.set_tracing_active(True)

# Reset to configuration default
pointguard.reset_tracing_to_config_default()
```

This is useful for:
- Performance optimization in high-throughput systems
- Conditional tracing based on user type or request parameters
- Debugging and troubleshooting without redeployment
- Implementing sampling strategies
- Calls already in progress when you disable tracing still finish logging.

See `examples/dynamic_tracing_cookbook.py` for comprehensive usage patterns.

## Basic Usage: Tracing

The easiest way to log traces is to use the `@pointguard.track` decorator:

```python
import pointguard

# Ensure pointguard is configured (see Configuration section above)
# pointguard.configure(...)

@pointguard.track
def my_llm_function(user_question: str) -> str:
    # Your LLM call or business logic here
    # For example:
    # response = openai.ChatCompletion.create(...)
    response = f"Echoing: {user_question}"

    # You can add metadata to your trace
    pointguard.set_tags(["example", "basic-usage"])
    pointguard.log_metadata({"question_length": len(user_question)})

    return response

my_llm_function("Hello, pointguard!")
```
Traces will appear in your configured pointguard project. pointguard also offers many direct [integrations](https://www.comet.com/docs/pointguard/integrations/overview/) for popular LLM frameworks.

## CLI Commands

pointguard provides powerful CLI commands for exporting and importing data between projects:

- **Export**: Export traces, datasets, and prompts from projects to local JSON files
- **Import**: Import data from local files into projects
- **Migration**: Move data between projects or environments
- **Backup**: Create local backups of your project data

For detailed information about the CLI export/import functionality, see [README-IMPORT-EXPORT.md](README-IMPORT-EXPORT.md).

## Development & Contribution Guidelines

For a more general contribution guide (backend + frontend + SDK) see our root [Contribution guide](../../CONTRIBUTING.md).

# Coding guidelines
This guide is still in progress, however, it already contains useful information that you should know before submitting your PR.

## General
We care a lot about the code maintainability. Well-organized logic which is easy to extend, re-factor and, most importantly - **read**, is what we are striving for.
1. Follow [SOLID](https://realpython.com/solid-principles-python/) principles. Pay special attention to the "Single Responsibility" one.
2. Avoid large modules, large classes, and large functions. Separate the code properly and describe this separation with names, not with comments. (See [1])
3. If the name is not used outside of the class/module - it should be `_protected`.
4. Don't violate the access rules! We know that Python allows you to access _protected/__private variables, but in pointguard we are quite strict about not abusing that, whether it's an internal code or a test (don't forget about [3]!).
5. Use comments only for something non-trivial that is hard to describe in any other way. Apart from these cases, comments should be used to answer the question "Why?" not "What?".

## Imports
1. Import module - not name.
    Instead of this:
    ```python
    from threading import Thread  # bad!
    thread = Thread()
    ```
    do this:
    ```python
    import threading  # good!
    thread = threading.Thread
    ```

2. If the import statement is too big, you can do the following
    ```python
    from pointguard.rest_api.core import error as rest_api_error  # ok!
    ```

3. If you are working in the namespace, you likely don't need to keep most of the parent namespaces
    ```python
    # inside pointguard.api_objects.dataset
    from . import dataset_item  # ok!
    ```

4. Of course, there might be exceptions from this rule, for example, some common types can be imported as is.
    ```python
    from typing import Dict, List  # ok!
    from pointguard.types import FeedbackScoreDict  # ok!
    ```

## Naming
1. Avoid abbreviations. In the vast majority of cases, it is not a problem to use variable names. People spend more time understanding what "fs" means than reading the word "files" or "file_system".
   ```python
   for d in dataset_items:  # bad!

   for item in dataset_items:  # ok!
       ...
   for dataset_item in dataset_items  # ok!
       ...
   ```
2. Avoid creating modules like `utils.py`, `helpers.py`, `misc.py` etc. Especially in the big namespaces. They can quickly become dumps where people put everything that they haven't been able to create a better place for in 10 seconds after they started thinking about it. You can create those files though, but they should be localized in their namespaces designed for some specific features. In vast majority of cases there are better module names.

## Testing
We highly encourage writing tests and we develop a lot of features in a test-driven way.
1. Test public API, don't violate privacy.
2. If you are an external contributor - make sure that the unit tests and e2e tests are green (they can be executed anywhere because they don't require any API keys or permissions). For internal pointguard developers everything should be green in the CI.
3. If you have `if-statements` in your code or some non-trivial boiler-plate code - it's probably a reason to think about add some unit tests for that. The more complex your code, the higher chance you'll be asked to provide unit tests for it.
4. If you are introducing a new feature that includes communication with the backend - it's better to add some e2e tests for that (at least the happy flow one).
5. Avoid testing with e2e tests something that can be tested with unit tests. E2E tests are time-consuming.
6. If you are introducing a change in one of the integrations (or a new integration), make sure the integration tests are working. They usually require API keys configured for the services the integration works with. When the external contributor opens a PR, their tests will not use our Github secrets so consider providing your repo with an API key required for the integration. In that case, we will see that the tests are green.
7. We are using `fake_backend` fixture together with a special pointguard assertions DSL(domain-specific language) for a lot of unit tests and library integration tests. We encourage you to use it as well! There is plenty of examples, you can take a look at `tests/unit/decorator/test_tracker_outputs.py` or `tests/library_integration/openai/test_openai.py`. It provides a pretty simple API for specifying the traces content you expect your feature to log.