Skip to content

Commit db23727

Browse files
TexasCodingTexasCoding
committed
update policies
1 parent 011901b commit db23727

File tree

2 files changed

+330
-0
lines changed

2 files changed

+330
-0
lines changed

‎CONTRIBUTING.md‎

Lines changed: 220 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,220 @@
1+
# Contributing to ProjectX Python SDK
2+
3+
Thank you for considering contributing to the ProjectX Python SDK! This document provides guidelines and instructions to help you contribute effectively.
4+
5+
## Table of Contents
6+
- [Development Setup](#development-setup)
7+
- [Code Style and Conventions](#code-style-and-conventions)
8+
- [Pull Request Process](#pull-request-process)
9+
- [Testing Guidelines](#testing-guidelines)
10+
- [Documentation Requirements](#documentation-requirements)
11+
- [Architecture Guidelines](#architecture-guidelines)
12+
13+
## Development Setup
14+
15+
### Prerequisites
16+
- Python 3.12 or higher
17+
- UV package manager (recommended)
18+
19+
### Local Development Environment
20+
21+
1. **Clone the repository**
22+
```bash
23+
git clone https://github.com/yourusername/project-x-py.git
24+
cd project-x-py
25+
```
26+
27+
2. **Set up the development environment with UV (recommended)**
28+
```bash
29+
# Install UV if you haven't already
30+
curl -sSf https://install.determinate.systems/uv | python3 -
31+
32+
# Install development dependencies
33+
uv sync
34+
```
35+
36+
3. **Alternative setup with pip**
37+
```bash
38+
pip install -e ".[dev]"
39+
```
40+
41+
4. **Verify installation**
42+
```bash
43+
uv run pytest -xvs tests/
44+
```
45+
46+
## Code Style and Conventions
47+
48+
This project follows strict code style guidelines to maintain consistency and quality:
49+
50+
### Python Version
51+
- Use Python 3.12+ features and syntax
52+
- Use modern typing features (e.g., `int | None` instead of `Optional[int]`)
53+
54+
### Formatting and Linting
55+
- We use Ruff for both formatting and linting
56+
- Always run these commands before submitting code:
57+
```bash
58+
# Format code
59+
uv run ruff format .
60+
61+
# Lint code (with safe auto-fix)
62+
uv run ruff check --fix .
63+
```
64+
65+
### Type Hints
66+
- All code MUST include comprehensive type hints
67+
- Use Python 3.10+ union syntax: `int | None` instead of `Optional[int]`
68+
- Use `isinstance(x, (A | B))` instead of `isinstance(x, (A, B))`
69+
- Use `dict[str, Any]` instead of `Dict[str, Any]`
70+
71+
### Async/Await
72+
- This project uses an async-first architecture
73+
- All I/O operations must be async
74+
- Use `async/await` consistently
75+
- Use appropriate locking mechanisms for thread safety
76+
77+
### Data Processing
78+
- Use Polars exclusively for DataFrame operations
79+
- Never include Pandas fallbacks or compatibility code
80+
- Use vectorized operations where possible
81+
- Validate DataFrame schemas before operations
82+
83+
### Error Handling
84+
- Wrap ProjectX API calls in try-catch blocks
85+
- Log errors with context: `self.logger.error(f"Error in {method_name}: {e}")`
86+
- Return meaningful error responses instead of raising exceptions
87+
- Validate input parameters and API data
88+
89+
## Pull Request Process
90+
91+
1. **Create a feature branch** from `main`
92+
```bash
93+
git checkout -b feature/your-feature-name
94+
```
95+
96+
2. **Implement your changes** following the code style guidelines
97+
98+
3. **Add/update tests** to cover your changes
99+
100+
4. **Ensure all tests pass**
101+
```bash
102+
uv run pytest -xvs tests/
103+
```
104+
105+
5. **Format and lint your code**
106+
```bash
107+
uv run ruff format .
108+
uv run ruff check --fix .
109+
```
110+
111+
6. **Update documentation** to reflect your changes
112+
113+
7. **Submit a pull request** with:
114+
- Clear description of the changes
115+
- Reference to any related issues
116+
- Explanation of how to test the changes
117+
118+
8. **Address review feedback** until your PR is approved
119+
120+
## Testing Guidelines
121+
122+
All code contributions should include appropriate tests:
123+
124+
### Test Coverage
125+
- Maintain or improve test coverage with each PR
126+
- Write both unit and integration tests
127+
128+
### Test Structure
129+
- Follow the existing test pattern in the `tests/` directory
130+
- Use descriptive test names (`test_should_validate_market_data`)
131+
- Include tests for both success and failure scenarios
132+
133+
### Test Organization
134+
- Unit tests: Focus on testing individual functions/methods
135+
- Integration tests: Test the interaction between components
136+
- Comprehensive tests: Test full workflows and realistic scenarios
137+
138+
### Test Execution
139+
```bash
140+
# Run all tests
141+
uv run pytest
142+
143+
# Run specific test file
144+
uv run pytest tests/test_async_client.py
145+
146+
# Run tests with coverage report
147+
uv run pytest --cov=src/project_x_py
148+
```
149+
150+
## Documentation Requirements
151+
152+
Good documentation is essential for this project:
153+
154+
### Code Documentation
155+
- All public classes, methods, and functions MUST have docstrings
156+
- Follow the established docstring format (Google style)
157+
- Include Args and Returns sections in docstrings
158+
- Document expected parameter types and return values
159+
- Include examples for complex methods
160+
161+
### README and Example Updates
162+
- Update the README.md when adding new features
163+
- Add examples to the `examples/` directory for significant features
164+
- Keep the documentation synchronized with the code
165+
166+
### API Reference Documentation
167+
- Add/update Sphinx documentation for public APIs
168+
- Build and verify documentation changes:
169+
```bash
170+
cd docs
171+
uv run sphinx-build -b html . _build/html
172+
```
173+
174+
## Architecture Guidelines
175+
176+
### Project Structure
177+
- Maintain the existing modular architecture
178+
- Place new files in appropriate modules
179+
- Consider impacts on existing components
180+
181+
### Performance Considerations
182+
- Implement time window filtering for analysis methods
183+
- Filter data BEFORE processing to reduce memory usage
184+
- Implement appropriate data cleanup for old entries
185+
- Use appropriate data types (int vs float vs str)
186+
- Consider memory management in all components
187+
188+
### API Design
189+
- Follow the established API patterns
190+
- Use async context managers for resource management
191+
- Implement proper error handling and validation
192+
- Provide clear feedback on API errors
193+
194+
### ProjectX Platform Integration
195+
- Follow the ProjectX API documentation
196+
- Use configuration objects for URL management
197+
- Never hardcode platform URLs
198+
- Handle all required/optional fields in API responses
199+
- Support both TopStepX endpoints and custom endpoints
200+
201+
## Reporting Issues
202+
203+
If you encounter any bugs or have feature requests:
204+
205+
1. Check if the issue already exists in the GitHub issue tracker
206+
2. If not, create a new issue with:
207+
- Detailed description of the issue
208+
- Steps to reproduce
209+
- Expected vs actual behavior
210+
- Environment information (Python version, OS, etc.)
211+
212+
## License
213+
214+
By contributing to this project, you agree that your contributions will be licensed under the project's MIT license.
215+
216+
## Questions?
217+
218+
If you have any questions or need help, please open an issue or contact the project maintainers.
219+
220+
Thank you for contributing to the ProjectX Python SDK!

‎SECURITY.md‎

Lines changed: 110 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,110 @@
1+
# Security Policy
2+
3+
## Overview
4+
5+
The ProjectX Python SDK provides access to trading functionality and financial data. We take security seriously and are committed to ensuring the SDK is secure for all users. This document outlines our security practices and how to report vulnerabilities.
6+
7+
## Supported Versions
8+
9+
We currently provide security updates for the following versions:
10+
11+
| Version | Supported |
12+
| ------- | ------------------ |
13+
| 2.0.x | :white_check_mark: |
14+
| 1.x.x | :x: |
15+
16+
Note: Version 2.0.0 was a complete rewrite with an async-only architecture, and all previous synchronous APIs were removed.
17+
18+
## Reporting a Vulnerability
19+
20+
If you discover a security vulnerability within the ProjectX Python SDK, please follow these steps for responsible disclosure:
21+
22+
1. **DO NOT** disclose the vulnerability publicly or on GitHub issues
23+
2. Send an email to [email protected] with:
24+
- A description of the vulnerability
25+
- Steps to reproduce
26+
- Potential impact
27+
- Any suggested mitigations (optional)
28+
3. Allow us reasonable time to address the issue before public disclosure
29+
30+
## What to Expect
31+
32+
After submitting a security vulnerability:
33+
34+
- We will acknowledge receipt of your report within 48 hours
35+
- We will provide a more detailed response within 7 days indicating next steps
36+
- We will work with you to understand and address the issue
37+
- We will keep you informed about our progress
38+
- We will credit you when we publish the vulnerability (unless you prefer to remain anonymous)
39+
40+
## Security Update Process
41+
42+
When security vulnerabilities are discovered:
43+
44+
1. We assess the severity and impact
45+
2. We develop and test a fix
46+
3. We release a security update with appropriate version bump
47+
4. We publish a security advisory through GitHub's security advisories feature
48+
5. For critical issues, we may directly notify users who have provided contact information
49+
50+
## Best Practices for SDK Users
51+
52+
To ensure secure use of the ProjectX Python SDK:
53+
54+
### Authentication & API Keys
55+
56+
- Store API keys and credentials securely using environment variables or secure vaults
57+
- Never commit API keys to version control
58+
- Use the recommended config file path (`~/.config/projectx/config.json`) with appropriate file permissions
59+
- Regularly rotate your API keys
60+
61+
### Network Security
62+
63+
- Use HTTPS connections to the API (default in the SDK)
64+
- Consider implementing IP restrictions if supported by your broker or trading platform
65+
- Monitor for unusual API activity
66+
67+
### Dependency Management
68+
69+
- Regularly update the SDK to the latest version
70+
- Use dependency scanning tools to ensure all dependencies are secure
71+
- Lock dependency versions for production deployments
72+
73+
### Operational Security
74+
75+
- Implement proper logging for audit trails
76+
- Consider limiting trade sizes and implementing circuit breakers for automated trading
77+
- Test extensively before deploying to production
78+
- Implement monitoring for abnormal behavior
79+
80+
### Code Security
81+
82+
- Validate all input data
83+
- Do not modify the SDK core unless absolutely necessary
84+
- If extending the SDK, follow secure coding practices
85+
- Review the source code of any plugins or extensions before use
86+
87+
## Vulnerability Disclosure Policy
88+
89+
We follow these guidelines for disclosing vulnerabilities:
90+
91+
1. Security issues are addressed promptly
92+
2. Fixes are thoroughly tested before release
93+
3. Vulnerabilities are publicly disclosed after a fix is available
94+
4. Users are encouraged to update as soon as possible
95+
5. Credits are given to reporters who follow the responsible disclosure process
96+
97+
## Security Contacts
98+
99+
For security concerns, please contact:
100+
- Email: [email protected]
101+
- PGP Key: [Security PGP Key](https://projectx.com/pgp-key.txt)
102+
103+
## Compliance
104+
105+
When using this SDK for trading:
106+
- Ensure compliance with all relevant financial regulations
107+
- Be aware that this SDK handles financial data that may be subject to additional security requirements
108+
- Consider implementing additional security measures for production trading systems
109+
110+
We appreciate your efforts in keeping the ProjectX Python SDK and its users secure!

0 commit comments

Comments
 (0)