Python project structure — pyproject.toml, src layout, __init__.py, .gitignore, dependency groups, type hints, py.typed, test structure, entry points, ruff/mypy configuration
91
87%
Does it follow best practices?
Impact
99%
1.03xAverage score across 5 eval scenarios
Passed
No known issues
A data engineering team frequently writes the same validation logic across multiple projects: checking CSV column types, validating email formats, verifying date ranges, and ensuring numeric values are within bounds. They want to extract this into a reusable Python library that can be installed from their internal PyPI registry.
The library needs to be properly packaged so other teams can pip install it and get full type checking support in their IDEs. It should use the src layout since it will be distributed as a package.
Produce a complete library project structure with:
pyproject.toml -- [build-system] with hatchling (or setuptools), [project] with name, version, description, requires-python >= 3.11, minimal dependencies (none or just pydantic), dev/test optional dependency groups, [tool.ruff] and [tool.mypy] configuration with strict mode.gitignore -- venv, pycache, dist, egg-info, .env, coverage, mypy cachesrc/datavalidator/ package with:
__init__.py -- public API re-exports (Validator, ValidationError, validate)py.typed -- marker file for PEP 561 typed packagevalidators.py -- Core validation functions (validate_email, validate_date_range, validate_numeric_range, validate_column_types)models.py -- Data models: ValidationRule, ValidationResult, ColumnSpecexceptions.py -- Custom exceptions: ValidationError, SchemaErrortests/ with __init__.py, conftest.py, and test files for validators and modelsAll functions must have complete type annotations. The library should be installable with pip install -e ".[dev]".
evals
scenario-1
scenario-2
scenario-3
scenario-4
scenario-5
skills
python-project-structure
verifiers