editable install toml - #40

• Add PEP 517/518 build metadata via a new pyproject.toml.
• Install the repo as an editable package in CI to avoid manual PYTHONPATH wiring.
• Simplify the test step by relying on standard package import resolution.

graph TD
  A["GitHub Actions job"] --> B["pip install -r requirements-dev"] --> C["pip install -e ."] --> D["Editable package"] --> E["pytest"]
  D --> F["Algorithms* modules"]
  C --> G["pyproject.toml"]
  subgraph Legend
    direction LR
    _job["CI step"] ~~~ _cfg["Config file"] ~~~ _pkg["Python package"]
  end

Loading

The following are alternative approaches to this PR:

1. Keep PYTHONPATH in CI (no packaging)

• ➕ No packaging configuration needed
• ➕ Works for simple script-style repos
• ➖ More brittle import behavior vs standard packaging
• ➖ Harder to mirror local/dev environments and tools
• ➖ Does not validate that the project is actually installable

2. Non-editable install (pip install .)

• ➕ Closer to a real release install
• ➕ Avoids editable-mode edge cases
• ➖ Slower iteration for CI/debugging
• ➖ Can mask issues that only appear during editable development workflows

3. Use Poetry/Hatch for packaging

• ➕ Richer dependency/lock management and tooling conventions
• ➕ Often simpler metadata management for modern Python projects
• ➖ Introduces a new toolchain and conventions
• ➖ May be unnecessary overhead for a lightweight examples repo

Recommendation: The PR’s approach (adding pyproject.toml and using pip install -e . in CI) is the most straightforward modernization: it removes the PYTHONPATH workaround while validating that the repository is installable using standard Python packaging. Consider switching to pip install . only if you specifically want CI to emulate a release install rather than a dev workflow.

Other (2) +20 / -2

cicd.ymlInstall project in editable mode for tests +1/-2

Install project in editable mode for tests

• Adds 'pip install -e .' to the CI setup step and removes the PYTHONPATH environment override for pytest, relying on standard package installation for imports.

.github/workflows/cicd.yml

pyproject.tomlAdd setuptools-based pyproject.toml with package discovery +19/-0

Add setuptools-based pyproject.toml with package discovery

• Introduces PEP 517 build configuration and project metadata, configuring setuptools to discover and include 'Algorithms*' packages from the repository root.

pyproject.toml

Description

pyproject.toml limits package discovery to Algorithms*, but tests import modules under LLMs,
so the new editable install does not install all code under test and test imports will only work
when the repo root happens to be on sys.path (e.g., running from the checkout). This undermines
the intent of removing PYTHONPATH in CI and makes installed usage inconsistent.

Code

pyproject.toml[R14-19]

+[tool.setuptools]
+package-dir = {"" = "."}
+
+[tool.setuptools.packages.find]
+where = ["."]
+include = ["Algorithms*"]

Evidence

The setuptools discovery config includes only Algorithms*, while tests import LLMs.*; therefore,
an editable install driven by this metadata will not cover the LLMs modules that tests require.

pyproject.toml[14-19]
tests/test_batch_agg.py[1-5]
tests/test_pooling.py[1-4]
.github/workflows/cicd.yml[23-31]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`pyproject.toml` only discovers packages matching `Algorithms*`, but the test suite imports from `LLMs.*`. As a result, `pip install -e .` does not install/expose `LLMs` as part of the editable install, and tests/imports work only if the repository root is on `sys.path`.

## Issue Context
CI now runs `pip install -e .` and no longer sets `PYTHONPATH`, so the install metadata should accurately reflect what code is expected to be importable.

## Fix Focus Areas
- pyproject.toml[14-19]
- .github/workflows/cicd.yml[23-30]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The project metadata sets dependencies = [], but repository code imports pydantic, so a plain
pip install -e . (or wheel install) will produce an environment where imports fail unless users
separately install dependencies. This makes the new pyproject-based install path unreliable.

Code

pyproject.toml[R5-13]

+[project]
+name = "python-examples"
+version = "0.1.0"
+description = "Algorithms and systems examples repo"
+readme = "README.md"
+requires-python = ">=3.8"
+
+dependencies = []
+

Evidence

dependencies is empty in pyproject.toml, while Algorithms/slidingWindow/longestUnique.py
imports pydantic, demonstrating a missing declared runtime dependency.

pyproject.toml[5-13]
Algorithms/slidingWindow/longestUnique.py[1-7]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`pyproject.toml` declares no runtime dependencies, but project modules import third-party libraries (e.g., `pydantic`). Installing the project via pip will not pull these in, causing runtime import errors in fresh environments.

## Issue Context
CI currently installs `requirements-dev.txt` (which includes `pydantic`), masking the packaging problem; users/installations that rely on `pyproject.toml` metadata will break.

## Fix Focus Areas
- pyproject.toml[5-13]
- Algorithms/slidingWindow/longestUnique.py[1-7]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools