Skip to content

Latest commit

 

History

History
executable file
·
102 lines (75 loc) · 2.11 KB

File metadata and controls

executable file
·
102 lines (75 loc) · 2.11 KB

Contributing to DeepEval MultiRun

Thank you for your interest in contributing to DeepEval MultiRun! This document provides guidelines for contributing to the project.

Development Setup

  1. Clone the repository:

    git clone https://github.com/MRLab12/deepeval-multirun.git
    cd deepeval-multirun
  2. Create a virtual environment:

    python -m venv venv
    source venv/bin/activate  # On Windows: venv\Scripts\activate
  3. Install in development mode:

    pip install -e ".[dev]"

Running Tests

# Run all tests
pytest

# Run with coverage
pytest --cov=deepeval_multirun --cov-report=html

# Run specific test file
pytest tests/test_core.py

# Run with verbose output
pytest -v

Code Quality

Before submitting a pull request, ensure your code passes all quality checks:

# Format code
black src tests

# Lint code
ruff check src tests

# Type checking
mypy src

Pull Request Process

  1. Fork the repository
  2. Create a feature branch (git checkout -b feat/amazing-feature)
  3. Make your changes
  4. Add tests for new functionality
  5. Ensure all tests pass
  6. Commit your changes using conventional commits
  7. Push to your fork
  8. Open a pull request

Commit Message Convention

We use Conventional Commits:

  • feat: New feature
  • fix: Bug fix
  • docs: Documentation changes
  • test: Adding or updating tests
  • refactor: Code refactoring
  • chore: Maintenance tasks

Example:

feat: add support for custom confidence thresholds
fix: resolve race condition in multi-run evaluation
docs: update README with pytest integration example

Code Style

  • Follow PEP 8 guidelines
  • Use type hints for all functions
  • Write docstrings for all public functions and classes
  • Keep functions small and focused
  • Prefer clarity over cleverness

Testing Guidelines

  • Write tests for all new features
  • Maintain or improve code coverage
  • Use descriptive test names
  • Mock external dependencies
  • Test edge cases and error conditions

Questions?

Feel free to open an issue for any questions or concerns!