[FEATURE] PEP 8 Support

[Vicente-Pastor]

Summary

The project currently uses Black (line-length 88) and isort for formatting but lacks a linter to enforce PEP 8 naming, unused imports, and other non-formatting rules.

Proposal

Add Ruff as a single-tool replacement for flake8/pycodestyle/pydocstyle with auto-fix support.

Suggested pyproject.toml configuration

[tool.ruff]
line-length = 88
target-version = "py312"

[tool.ruff.lint]
select = ["E", "F", "W", "I", "N", "UP", "B"]

Rule sets

Code	Category	Description
E	pycodestyle errors	Core PEP 8 style
F	pyflakes	Unused imports, undefined names
W	pycodestyle warnings	Whitespace issues
I	isort	Import ordering (replaces standalone isort)
N	pep8-naming	Naming conventions
UP	pyupgrade	Modernize Python syntax
B	flake8-bugbear	Common bug patterns

Rollout plan

1. Add Ruff to [project.optional-dependencies] dev
2. Run ruff check --fix . for auto-fixable violations
3. Run black . and isort . to reformat
4. Manual review for remaining violations
5. Add ruff check to CI pipeline
6. Use git blame --ignore-rev to exclude the formatting commit

Notes

• Ruff is 10-100x faster than flake8/pylint
• Already Black-compatible out of the box
• Existing code largely follows PEP 8 naming conventions already
• Keep line-length at 88 to match existing Black config
• Do this as a separate PR to avoid polluting git blame

[sergio-sisternes-epam]

Thanks for the well-structured proposal, @Vicente-Pastor! The suggested Ruff configuration and rollout plan are solid.

Accepting this as-is. A few notes for whoever picks this up:

• The git blame --ignore-rev step is important -- please include it in the PR description so reviewers remember to add the formatting commit SHA to .git-blame-ignore-revs.
• Keep the formatting commit separate from the config/CI changes for clean review.
• The rule set (E, F, W, I, N, UP, B) looks well-scoped -- no need to go broader initially.

Marking as good first issue since the rollout is well-defined and mostly automated. Contributions welcome!

[github-actions]

Triage decision

accept

Proposed labels

area/testing
area/docs-site
type/automation
status/accepted
priority/low
good first issue

Milestone

0.9.4

Suggested next action

Start with adding Ruff to [project.optional-dependencies] dev with rule set E, F, W only; run ruff check --fix .; open a draft PR to gauge the violation count before committing to N, UP, and B.

Suggested issue comment

Thanks for the well-researched proposal, `@Vicente-Pastor`! Adding Ruff as a linter is a solid direction -- it is Black-compatible, already widely adopted in the Python ecosystem, and the rule set you proposed is sensible.

One suggestion on the rollout: consider starting with just E, F, W (the core PEP 8 errors and warnings) for the first PR. N (naming) and UP (pyupgrade) can generate hundreds of violations across a codebase and make the diff hard to review; landing them incrementally after the baseline is established keeps each PR focused.

Your `git blame --ignore-rev` plan for the formatting commit is the right approach -- add `.git-blame-ignore-revs` at the repo root and document it in CONTRIBUTING.md alongside the updated formatting guidance (replacing the isort step with Ruff).

This is a great `good first issue` for someone comfortable with Ruff. Feel free to open a draft PR and we will review!

Per-lens notes (collapsed)

DevX UX Expert -- User-Need Reviewer

This is a contributor DX improvement with no end-user-facing behavior change. Adding Ruff as a linter enforces naming, unused imports, and other non-formatting rules that Black does not cover. The tooling choice is sound: Ruff is 10-100x faster than flake8, is Black-compatible out of the box, and replaces standalone isort. The proposed pyproject.toml configuration is well-structured and ready to use.

Supply Chain Security Expert -- Risk-Surface Reviewer

No risk-surface implication. Ruff (by Astral) is a well-audited, widely-adopted tool in the Python ecosystem with a transparent supply chain. Adding it as a dev dependency does not affect the APM runtime or install surface.

OSS Growth Hacker -- Contributor-Tone Reviewer

Vicente-Pastor has author_association=NONE on microsoft/apm, activating this lens. The proposal is unusually well-structured for a first contribution -- it includes a concrete pyproject.toml config, a rule-set table, and a rollout plan. The reply should warmly acknowledge this quality. The good first issue framing is accurate: implementing this is mechanical work (run ruff --fix, review output, add to CI) that a new contributor can execute well with guidance. Encourage them to start with a smaller rule set to make the PR reviewable.

Python Architect -- Architecture Reviewer

The proposed rule set (E, F, W, I, N, UP, B) is reasonable but ambitious for a first pass. N (pep8-naming) and UP (pyupgrade) may generate 100+ violations across the codebase, making the PR difficult to review. Recommendation: land E, F, W first (fewest violations, highest signal), then add I (import ordering, which replaces isort), and defer N, UP, B to follow-up PRs. The mechanical refactor is well-understood and feasibility is high. No cross-cutting design concern.

Doc Writer -- Documentation Reviewer

CONTRIBUTING.md currently references Black and isort; Ruff replaces isort and supplements Black. The CONTRIBUTING.md update (replacing the isort step with Ruff, adding a note about the .git-blame-ignore-revs file) is implied and should land in the same PR as the tooling setup. area/docs-site is included as a secondary label since CONTRIBUTING.md is a documentation artifact.

APM CEO -- Triage Arbiter

Human labels accepted and good first issue are authoritative -- the direction is approved. This is a good-quality, well-scoped contribution from a new contributor. The Python Architect's caution about rule set scope is valid and incorporated in the suggested reply. Milestone 0.9.4 as a patch-ready developer tooling improvement. Priority/low since it has no user-facing impact and no urgency.

{
  "decision": "accept",
  "decision_detail": "",
  "theme": null,
  "areas": ["area/testing", "area/docs-site"],
  "type": "type/automation",
  "status": "status/accepted",
  "priority": "priority/low",
  "preserved_labels": ["good first issue"],
  "milestone": "0.9.4",
  "next_action": "Add Ruff to dev dependencies with rule set E, F, W first; run ruff check --fix; update CONTRIBUTING.md to replace isort step with Ruff; add ruff check to CI.",
  "comment_markdown": "Thanks for the well-researched proposal, `@Vicente-Pastor`! Adding Ruff as a linter is a solid direction -- it is Black-compatible, already widely adopted in the Python ecosystem, and the rule set you proposed is sensible.\n\nOne suggestion on the rollout: consider starting with just E, F, W (the core PEP 8 errors and warnings) for the first PR. N (naming) and UP (pyupgrade) can generate hundreds of violations across a codebase and make the diff hard to review; landing them incrementally after the baseline is established keeps each PR focused.\n\nYour `git blame --ignore-rev` plan for the formatting commit is the right approach -- add `.git-blame-ignore-revs` at the repo root and document it in CONTRIBUTING.md alongside the updated formatting guidance (replacing the isort step with Ruff).\n\nThis is a great `good first issue` for someone comfortable with Ruff. Feel free to open a draft PR and we will review!"
}

---

Triage status: agentic proposal pending human ratification.
Silence is approval. Maintainers can:

• Override any label or milestone above by editing it directly --
  human edits are authoritative and will not be reverted on
  subsequent runs.
• Re-trigger triage by applying the status/needs-triage label, or
  by removing status/triaged to enroll the issue in the next
  daily sweep.

Posted by the Triage Panel workflow. See .apm/skills/apm-triage-panel for the panel skill.

Generated by Triage Panel · ● 2.2M · ◷