From dd0b990ba51ce635d05cd17b85f48cc7449237b4 Mon Sep 17 00:00:00 2001 From: Mason Daugherty Date: Thu, 11 Dec 2025 01:51:00 -0500 Subject: [PATCH] chore(infra): delete copilot instructions (#34294) and some files we inherit from org root --- .github/CODE_OF_CONDUCT.md | 132 ------------- .github/CONTRIBUTING.md | 6 - .github/copilot-instructions.md | 330 -------------------------------- .github/pr-file-labeler.yml | 11 -- .github/workflows/v1_changes.md | 8 - 5 files changed, 487 deletions(-) delete mode 100644 .github/CODE_OF_CONDUCT.md delete mode 100644 .github/CONTRIBUTING.md delete mode 100644 .github/copilot-instructions.md delete mode 100644 .github/workflows/v1_changes.md diff --git a/.github/CODE_OF_CONDUCT.md b/.github/CODE_OF_CONDUCT.md deleted file mode 100644 index 12af532b48d..00000000000 --- a/.github/CODE_OF_CONDUCT.md +++ /dev/null @@ -1,132 +0,0 @@ -# Contributor Covenant Code of Conduct - -## Our Pledge - -We as members, contributors, and leaders pledge to make participation in our -community a harassment-free experience for everyone, regardless of age, body -size, visible or invisible disability, ethnicity, sex characteristics, gender -identity and expression, level of experience, education, socio-economic status, -nationality, personal appearance, race, caste, color, religion, or sexual -identity and orientation. - -We pledge to act and interact in ways that contribute to an open, welcoming, -diverse, inclusive, and healthy community. - -## Our Standards - -Examples of behavior that contributes to a positive environment for our -community include: - -* Demonstrating empathy and kindness toward other people -* Being respectful of differing opinions, viewpoints, and experiences -* Giving and gracefully accepting constructive feedback -* Accepting responsibility and apologizing to those affected by our mistakes, - and learning from the experience -* Focusing on what is best not just for us as individuals, but for the overall - community - -Examples of unacceptable behavior include: - -* The use of sexualized language or imagery, and sexual attention or advances of - any kind -* Trolling, insulting or derogatory comments, and personal or political attacks -* Public or private harassment -* Publishing others' private information, such as a physical or email address, - without their explicit permission -* Other conduct which could reasonably be considered inappropriate in a - professional setting - -## Enforcement Responsibilities - -Community leaders are responsible for clarifying and enforcing our standards of -acceptable behavior and will take appropriate and fair corrective action in -response to any behavior that they deem inappropriate, threatening, offensive, -or harmful. - -Community leaders have the right and responsibility to remove, edit, or reject -comments, commits, code, wiki edits, issues, and other contributions that are -not aligned to this Code of Conduct, and will communicate reasons for moderation -decisions when appropriate. - -## Scope - -This Code of Conduct applies within all community spaces, and also applies when -an individual is officially representing the community in public spaces. -Examples of representing our community include using an official e-mail address, -posting via an official social media account, or acting as an appointed -representative at an online or offline event. - -## Enforcement - -Instances of abusive, harassing, or otherwise unacceptable behavior may be -reported to the community leaders responsible for enforcement at -conduct@langchain.dev. -All complaints will be reviewed and investigated promptly and fairly. - -All community leaders are obligated to respect the privacy and security of the -reporter of any incident. - -## Enforcement Guidelines - -Community leaders will follow these Community Impact Guidelines in determining -the consequences for any action they deem in violation of this Code of Conduct: - -### 1. Correction - -**Community Impact**: Use of inappropriate language or other behavior deemed -unprofessional or unwelcome in the community. - -**Consequence**: A private, written warning from community leaders, providing -clarity around the nature of the violation and an explanation of why the -behavior was inappropriate. A public apology may be requested. - -### 2. Warning - -**Community Impact**: A violation through a single incident or series of -actions. - -**Consequence**: A warning with consequences for continued behavior. No -interaction with the people involved, including unsolicited interaction with -those enforcing the Code of Conduct, for a specified period of time. This -includes avoiding interactions in community spaces as well as external channels -like social media. Violating these terms may lead to a temporary or permanent -ban. - -### 3. Temporary Ban - -**Community Impact**: A serious violation of community standards, including -sustained inappropriate behavior. - -**Consequence**: A temporary ban from any sort of interaction or public -communication with the community for a specified period of time. No public or -private interaction with the people involved, including unsolicited interaction -with those enforcing the Code of Conduct, is allowed during this period. -Violating these terms may lead to a permanent ban. - -### 4. Permanent Ban - -**Community Impact**: Demonstrating a pattern of violation of community -standards, including sustained inappropriate behavior, harassment of an -individual, or aggression toward or disparagement of classes of individuals. - -**Consequence**: A permanent ban from any sort of public interaction within the -community. - -## Attribution - -This Code of Conduct is adapted from the [Contributor Covenant][homepage], -version 2.1, available at -[https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][v2.1]. - -Community Impact Guidelines were inspired by -[Mozilla's code of conduct enforcement ladder][Mozilla CoC]. - -For answers to common questions about this code of conduct, see the FAQ at -[https://www.contributor-covenant.org/faq][FAQ]. Translations are available at -[https://www.contributor-covenant.org/translations][translations]. - -[homepage]: https://www.contributor-covenant.org -[v2.1]: https://www.contributor-covenant.org/version/2/1/code_of_conduct.html -[Mozilla CoC]: https://github.com/mozilla/diversity -[FAQ]: https://www.contributor-covenant.org/faq -[translations]: https://www.contributor-covenant.org/translations diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md deleted file mode 100644 index 66b0ccdfda6..00000000000 --- a/.github/CONTRIBUTING.md +++ /dev/null @@ -1,6 +0,0 @@ -# Contributing to LangChain - -Hi there! Thank you for even being interested in contributing to LangChain. -As an open-source project in a rapidly developing field, we are extremely open to contributions, whether they involve new features, improved infrastructure, better documentation, or bug fixes. - -To learn how to contribute to LangChain, please follow the [contribution guide here](https://docs.langchain.com/oss/python/contributing). diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md deleted file mode 100644 index b99ff1f48ac..00000000000 --- a/.github/copilot-instructions.md +++ /dev/null @@ -1,330 +0,0 @@ -# Global Development Guidelines for LangChain Projects - -## Core Development Principles - -### 1. Maintain Stable Public Interfaces ⚠️ CRITICAL - -**Always attempt to preserve function signatures, argument positions, and names for exported/public methods.** - -❌ **Bad - Breaking Change:** - -```python -def get_user(id, verbose=False): # Changed from `user_id` - pass -``` - -✅ **Good - Stable Interface:** - -```python -def get_user(user_id: str, verbose: bool = False) -> User: - """Retrieve user by ID with optional verbose output.""" - pass -``` - -**Before making ANY changes to public APIs:** - -- Check if the function/class is exported in `__init__.py` -- Look for existing usage patterns in tests and examples -- Use keyword-only arguments for new parameters: `*, new_param: str = "default"` -- Mark experimental features clearly with docstring admonitions (using MkDocs Material, like `!!! warning`) - -🧠 *Ask yourself:* "Would this change break someone's code if they used it last week?" - -### 2. Code Quality Standards - -**All Python code MUST include type hints and return types.** - -❌ **Bad:** - -```python -def p(u, d): - return [x for x in u if x not in d] -``` - -✅ **Good:** - -```python -def filter_unknown_users(users: list[str], known_users: set[str]) -> list[str]: - """Filter out users that are not in the known users set. - - Args: - users: List of user identifiers to filter. - known_users: Set of known/valid user identifiers. - - Returns: - List of users that are not in the known_users set. - """ - return [user for user in users if user not in known_users] -``` - -**Style Requirements:** - -- Use descriptive, **self-explanatory variable names**. Avoid overly short or cryptic identifiers. -- Attempt to break up complex functions (>20 lines) into smaller, focused functions where it makes sense -- Avoid unnecessary abstraction or premature optimization -- Follow existing patterns in the codebase you're modifying - -### 3. Testing Requirements - -**Every new feature or bugfix MUST be covered by unit tests.** - -**Test Organization:** - -- Unit tests: `tests/unit_tests/` (no network calls allowed) -- Integration tests: `tests/integration_tests/` (network calls permitted) -- Use `pytest` as the testing framework - -**Test Quality Checklist:** - -- [ ] Tests fail when your new logic is broken -- [ ] Happy path is covered -- [ ] Edge cases and error conditions are tested -- [ ] Use fixtures/mocks for external dependencies -- [ ] Tests are deterministic (no flaky tests) - -Checklist questions: - -- [ ] Does the test suite fail if your new logic is broken? -- [ ] Are all expected behaviors exercised (happy path, invalid input, etc)? -- [ ] Do tests use fixtures or mocks where needed? - -```python -def test_filter_unknown_users(): - """Test filtering unknown users from a list.""" - users = ["alice", "bob", "charlie"] - known_users = {"alice", "bob"} - - result = filter_unknown_users(users, known_users) - - assert result == ["charlie"] - assert len(result) == 1 -``` - -### 4. Security and Risk Assessment - -**Security Checklist:** - -- No `eval()`, `exec()`, or `pickle` on user-controlled input -- Proper exception handling (no bare `except:`) and use a `msg` variable for error messages -- Remove unreachable/commented code before committing -- Race conditions or resource leaks (file handles, sockets, threads). -- Ensure proper resource cleanup (file handles, connections) - -❌ **Bad:** - -```python -def load_config(path): - with open(path) as f: - return eval(f.read()) # ⚠️ Never eval config -``` - -✅ **Good:** - -```python -import json - -def load_config(path: str) -> dict: - with open(path) as f: - return json.load(f) -``` - -### 5. Documentation Standards - -**Use Google-style docstrings with Args and Returns sections for all public functions.** - -❌ **Insufficient Documentation:** - -```python -def send_email(to, msg): - """Send an email to a recipient.""" -``` - -✅ **Complete Documentation:** - -```python -def send_email(to: str, msg: str, *, priority: str = "normal") -> bool: - """ - Send an email to a recipient with specified priority. - - Args: - to: The email address of the recipient. - msg: The message body to send. - priority: Email priority level. - - Returns: - True if email was sent successfully, False otherwise. - - Raises: - InvalidEmailError: If the email address format is invalid. - SMTPConnectionError: If unable to connect to email server. - """ -``` - -**Documentation Guidelines:** - -- Types go in function signatures, NOT in docstrings -- Focus on "why" rather than "what" in descriptions -- Document all parameters, return values, and exceptions -- Keep descriptions concise but clear - -📌 *Tip:* Keep descriptions concise but clear. Only document return values if non-obvious. - -### 6. Architectural Improvements - -**When you encounter code that could be improved, suggest better designs:** - -❌ **Poor Design:** - -```python -def process_data(data, db_conn, email_client, logger): - # Function doing too many things - validated = validate_data(data) - result = db_conn.save(validated) - email_client.send_notification(result) - logger.log(f"Processed {len(data)} items") - return result -``` - -✅ **Better Design:** - -```python -@dataclass -class ProcessingResult: - """Result of data processing operation.""" - items_processed: int - success: bool - errors: List[str] = field(default_factory=list) - -class DataProcessor: - """Handles data validation, storage, and notification.""" - - def __init__(self, db_conn: Database, email_client: EmailClient): - self.db = db_conn - self.email = email_client - - def process(self, data: List[dict]) -> ProcessingResult: - """Process and store data with notifications. - - Args: - data: List of data items to process. - - Returns: - ProcessingResult with details of the operation. - """ - validated = self._validate_data(data) - result = self.db.save(validated) - self._notify_completion(result) - return result -``` - -**Design Improvement Areas:** - -If there's a **cleaner**, **more scalable**, or **simpler** design, highlight it and suggest improvements that would: - -- Reduce code duplication through shared utilities -- Make unit testing easier -- Improve separation of concerns (single responsibility) -- Make unit testing easier through dependency injection -- Add clarity without adding complexity -- Prefer dataclasses for structured data - -## Development Tools & Commands - -### Package Management - -```bash -# Add package -uv add package-name - -# Sync project dependencies -uv sync -uv lock -``` - -### Testing - -```bash -# Run unit tests (no network) -make test - -# Don't run integration tests, as API keys must be set - -# Run specific test file -uv run --group test pytest tests/unit_tests/test_specific.py -``` - -### Code Quality - -```bash -# Lint code -make lint - -# Format code -make format - -# Type checking -uv run --group lint mypy . -``` - -### Dependency Management Patterns - -**Local Development Dependencies:** - -```toml -[tool.uv.sources] -langchain-core = { path = "../core", editable = true } -langchain-tests = { path = "../standard-tests", editable = true } -``` - -**For tools, use the `@tool` decorator from `langchain_core.tools`:** - -```python -from langchain_core.tools import tool - -@tool -def search_database(query: str) -> str: - """Search the database for relevant information. - - Args: - query: The search query string. - """ - # Implementation here - return results -``` - -## Commit Standards - -**Use Conventional Commits format for PR titles:** - -- `feat(core): add multi-tenant support` -- `!fix(cli): resolve flag parsing error` (breaking change uses exclamation mark) -- `docs: update API usage examples` -- `docs(openai): update API usage examples` - -## Framework-Specific Guidelines - -- Follow the existing patterns in `langchain_core` for base abstractions -- Implement proper streaming support where applicable -- Avoid deprecated components - -### Partner Integrations - -- Follow the established patterns in existing partner libraries -- Implement standard interfaces (`BaseChatModel`, `BaseEmbeddings`, etc.) -- Include comprehensive integration tests -- Document API key requirements and authentication - ---- - -## Quick Reference Checklist - -Before submitting code changes: - -- [ ] **Breaking Changes**: Verified no public API changes -- [ ] **Type Hints**: All functions have complete type annotations -- [ ] **Tests**: New functionality is fully tested -- [ ] **Security**: No dangerous patterns (eval, silent failures, etc.) -- [ ] **Documentation**: Google-style docstrings for public functions -- [ ] **Code Quality**: `make lint` and `make format` pass -- [ ] **Architecture**: Suggested improvements where applicable -- [ ] **Commit Message**: Follows Conventional Commits format diff --git a/.github/pr-file-labeler.yml b/.github/pr-file-labeler.yml index 6f7b0f3d9ca..b3bbac33dde 100644 --- a/.github/pr-file-labeler.yml +++ b/.github/pr-file-labeler.yml @@ -148,16 +148,5 @@ documentation: - changed-files: - any-glob-to-any-file: - "**/*.md" - - "**/*.rst" - "**/README*" -# Security related changes -security: - - changed-files: - - any-glob-to-any-file: - - "**/*security*" - - "**/*auth*" - - "**/*credential*" - - "**/*secret*" - - "**/*token*" - - ".github/workflows/security*" diff --git a/.github/workflows/v1_changes.md b/.github/workflows/v1_changes.md deleted file mode 100644 index ee6baac103f..00000000000 --- a/.github/workflows/v1_changes.md +++ /dev/null @@ -1,8 +0,0 @@ -With the deprecation of v0 docs, the following files will need to be migrated/supported -in the new docs repo: - -- run_notebooks.yml: New repo should run Integration tests on code snippets? -- people.yml: Need to fix and somehow display on the new docs site - - Subsequently, `.github/actions/people/` -- _test_doc_imports.yml -- check-broken-links.yml