chore: add Copilot instructions and collections config#47
Conversation
Adds GitHub Copilot custom instructions following the pattern from canonical/copilot-collections. Files sourced from canonical/copilot-collections@v0.12.0 (core + common-python collections): - core-directive.instructions.md: Core interaction and code generation rules - instructions.instructions.md: Guidelines for writing instruction files - python-code-commenting.instructions.md: When/how to comment Python code Plus a project-specific instruction file: - distro-support.instructions.md: Project structure, tooling, data model, adding distributions, downloader patterns, type annotation rules, and CI matrix details Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a comprehensive set of custom instruction files for GitHub Copilot, including core directives, project-specific guidelines for the distro-support library, and standards for code commenting and instruction file creation. The review feedback correctly identifies an internal inconsistency in the distro-support guidelines regarding type annotation syntax and suggests correcting the technical justification for using Optional to ensure factual accuracy and consistency with the existing codebase.
| ## Type Annotations | ||
|
|
||
| - All public functions and methods must be fully annotated | ||
| - Use `Optional[X]` (not `X | None`) for compatibility with Python 3.10 |
There was a problem hiding this comment.
The reasoning 'for compatibility with Python 3.10' is confusing because Python 3.10 is the version that introduced the X | None (PEP 604) syntax. If the project requires Python 3.10+ (as stated in pyproject.toml), X | None is natively supported. If the goal is consistency with existing code or compatibility with versions older than 3.10, the description should be updated to reflect that.
| - Use `Optional[X]` (not `X | None`) for compatibility with Python 3.10 | |
| - Use `Optional[X]` (not `X | None`) for consistency with the existing codebase |
Not up to standards ⛔🔴 Issues
|
| Category | Results |
|---|---|
| BestPractice | 7 minor |
| CodeStyle | 7 minor |
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes. Give us feedback
- Fix line 61 example to use Optional[str] instead of str | None, consistent with the rule stated on line 119 - Fix line 119 reason: Python 3.10 is actually when X | None was *introduced* (PEP 604); the real reason is consistency with the existing codebase which uses Optional[X] throughout Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The project now requires Python 3.10+, which natively supports the X | None union syntax (PEP 604). Optional[X] appears in existing code from when the project supported Python 3.8, but new code should use X | None. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
1 participant
Adds GitHub Copilot custom instructions following the pattern established in canonical/copilot-collections and canonical/imagecraft#327.
Files
From canonical/copilot-collections @ v0.12.0
Sourced from the
coreandcommon-pythoncollections:core-directive.instructions.md(core): Core interaction rules — primacy of user directives, minimalist code generation, surgical modification, purposeful tool useinstructions.instructions.md(core): Guidelines for writing instruction files (applies to**/*.instructions.md)python-code-commenting.instructions.md(common-python): When and how to comment Python code — comment the why, not the whatCustom
distro-support.instructions.md: Project-specific guidance covering:uv,pytest,ruff,ty,make, LXD testing)SupportRangedata model and JSON file conventions (key ordering,nullvs empty string)(row.get("field") or None), HTTP error handling)tynarrowing quirks)