Thank you for your interest in contributing. This document covers the contribution process, code standards, and the plugin submission checklist. For all plugin-specific technical detail (ABC contract, DOM selection, config access, credential handling), see plugins/PLUGIN_DEV.md. This document links to that guide and does not duplicate its content.
All contributors are expected to follow the project's Code of Conduct. Please read it before participating.
Do not report security vulnerabilities in public GitHub issues. Follow the private disclosure process described in SECURITY.md.
- Fork the repository and clone your fork locally.
- Create a branch from
masterwith a descriptive name, for examplefeat/plugin-walmartorfix/bestbuy-checkout. - Implement your change. Keep commits small and focused; one logical change per commit.
- Test by running the full suite locally before opening a PR:
python -m pytest tests/ -q
- Open a pull request against
masterwith a clear description of what was changed and why.
Use Conventional Commits:
type(scope): short description under 72 characters
Optional body explaining why, not just what.
Types: feat, fix, docs, refactor, test, chore
- PEP 8 compliance required for all Python files.
- Variable and function names:
snake_case. - Maximum function length: 30 lines. Maximum file length: 300 lines.
- No new runtime dependencies without written justification in the PR explaining why no existing dependency covers the need.
The full plugin technical how-to (naming convention, ABC methods, DOM selection, config access, credential handling, and testing patterns) lives in plugins/PLUGIN_DEV.md. Read that guide first.
Every new-plugin PR must also satisfy the Plugin Submission Checklist below.
Before opening a plugin PR, verify each item:
-
File naming: Plugin file is named
shopbot_plugin_<name>.pyand lives in theplugins/directory. Files that do not match this pattern are never loaded by the registry. -
RetailerPlugin ABC compliance: Plugin class subclasses
RetailerPluginfromcore.plugin_baseand provides concrete implementations of both required async methods:check_availability(self, url: str) -> boolandauto_buy(self, url: str) -> bool. -
domain_patternsattribute: Plugin class defines adomain_patternsclass attribute (list of strings) that correctly identifies the target retailer's hostnames. The registry uses substring matching against the URL hostname. -
Test file included: A pytest test file (for example
tests/test_shopbot_plugin_<name>.py) is shipped with the plugin and covers at minimum ABC compliance. The full suite must be green:sh python -m pytest tests/ -q -
Anti-detection metadata declared: The plugin class declares all three required class attributes (see plugins/PLUGIN_DEV.md section 2 for the full ABC contract): -
difficulty: one of"easy","medium", or"hard"— reflects the anti-detection effort required to operate reliably on this retailer. -requires_proxy:TrueorFalse— setTrueif the plugin will not function correctly without a proxy configured inconfig.yml. -requires_captcha:TrueorFalse— setTrueif the plugin relies on the CAPTCHA solver integration to complete purchases.These three values are also used to populate the plugin's row in the wiki registry (see [docs/PLUGIN_REGISTRY.md](docs/PLUGIN_REGISTRY.md)). Ensure the PR description includes the row values so the maintainer can update the wiki when the PR is merged. -
No secrets or credentials committed: All credentials (email, password, API keys, tokens) are read from environment variables at runtime. Nothing sensitive is hardcoded in the plugin file, in
config.yml, or in any committed file. See plugins/PLUGIN_DEV.md section 6 for the approved pattern.