Thank you for your interest in contributing to Preswald! This document outlines the project structure, how to set up your development environment, and the guidelines for contributing. Whether you’re fixing bugs, adding new features, or improving documentation, we appreciate your time and effort.
- Project Structure
- Setup Guide
- Development Workflow
- Working with Forks & Keeping Your Branches in Sync
- Style Guide
- Code Quality
- Claiming an Issue
- Pull Request Guidelines
- Issue Reporting Guidelines
- Community Support
- Acknowledgments
preswald/
├── preswald/ # SDK + Python FastAPI backend
├── frontend/ # React + Vite frontend
├── examples/ # Sample apps to showcase Preswald's capabilities
├── tutorial/ # Tutorial for getting started with Preswald
├── tests/ # Unit and integration tests
├── pyproject.toml # Python package configuration
└── README.md # Project overview
- Fork the repository on GitHub.
- Clone your fork to your local machine:
git clone https://github.com/StructuredLabs/preswald.git cd preswald
We recommend using Conda to manage dependencies:
- [OPTIONAL] Install uv (this makes things so much faster):
curl -LsSf https://astral.sh/uv/install.sh | sh
- Create and activate a Conda environment:
conda create -n preswald python=3.10 -y conda activate preswald
- Install dependencies:
pip install -e ".[dev]" or uv pip install -e ".[dev]" # if you installed uv
- Set up pre-commit hooks:
pre-commit install
Build the frontend once
python -m preswald.build frontend
Or use watch mode to monitor changes and auto-rebuild
python -m preswald.build watch
Verify your setup by running the sample app:
cd examples/iris && preswald run
Here’s a quick summary of the contributing workflow:
- Fork and clone the repository.
- Create a new branch for your feature or bug fix:
git checkout -b feature/your-feature-name
- Make your changes and follow the Style Guide.
- Test your changes thoroughly.
- Push your branch to your fork:
git push origin feature/your-feature-name
- Open a Pull Request on the main repository.
When your forked repo gets out of sync with upstream (StructuredLabs/preswald), you’ll want to rebase your feature branch onto the latest upstream main to keep your commit history clean and linear. This avoids unnecessary merge commits that can clutter PR reviews. (If you haven’t already, add the upstream remote:
git remote add upstream [email protected]:StructuredLabs/preswald.git
)
Here’s a great guide on syncing forks: https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/syncing-a-fork
And here’s a solid intro to Git rebase: https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase
Follow these style guidelines to maintain consistency:
- Python: Use PEP 8.
- React: Follow React Best Practices.
- Formatting/Linting:
These are set up in the pre-commit hook - will run upon
git commit
on staged files. You don't have to run anything explicitly for formatting/linting- Python: we use
ruff
ruff format ruff check --fix
- JavaScript: we use
ESLint
with the provided configuration.npm run lint
- Python: we use
If you're using Preswald in your project, you might want to adopt similar standards. You can use our configuration files as a starting point:
.pre-commit-config.yaml
for pre-commit configurationpyproject.toml
for tool settings
These configurations ensure your code remains consistent with our standards when contributing back to the project.
- Create and activate another Conda environment for testing:
conda deactivate # if inside an existing conda env conda create -n preswald-test python=3.10 -y conda activate preswald-test
- Clear old builds:
rm -rf dist/ build/ *.egg-info
- Build frontend and backend:
python -m preswald.build frontend python -m build
- Install the pip package
uv pip install dist/preswald-0.xx.xx.tar.gz
- Run a test app
Make sure to do step 5 for all directories in
cd examples/earthquakes && preswald run
examples
, not justearthquakes
Issues are assigned and reviewed on a first come first serve basis. When you begin work on an issue, ensure you leave a comment acknowledging that you have done so such that other users who may be interested in the issue are aware of your work.
When submitting a PR:
- Use a descriptive branch name (e.g.,
feature/add-widget
orfix/typo-readme
). - Write a clear and concise PR title and description.
- Title: Start with a type prefix, such as
feat
,fix
, ordocs
. - Description: Include context, screenshots (if applicable), and links to relevant issues.
- Title: Start with a type prefix, such as
- Ensure your PR includes:
- Relevant tests for your changes.
- Updates to the documentation if applicable.
Example PR description:
feat: add new user authentication system
This PR adds user authentication via JWT tokens. Includes:
- Backend API endpoints for login and signup.
- React context integration for frontend.
- Unit tests for new functionality.
Fixes #42
When reporting an issue:
- Use a clear and concise title.
- Provide relevant details, such as:
- Steps to reproduce the issue.
- Expected vs. actual behavior.
- Environment details (OS, Python version, browser).
- Screenshots or logs, if applicable.
Example issue template:
**Describe the bug**
A clear and concise description of the issue.
**Steps to Reproduce**
1. Go to '...'
2. Click on '...'
3. See error
**Expected behavior**
A clear and concise description of what you expected to happen.
**Screenshots**
If applicable, add screenshots to help explain the issue.
**Environment**
- OS: [e.g., Windows, macOS, Linux]
- Python version: [e.g., 3.9]
- Browser: [e.g., Chrome, Firefox]
If you have questions or need help:
- Email us at [email protected].
- Join the Structured Users Slack for discussions and support: Structured Users Slack Invite.
We’re deeply grateful for your contributions! Every bug report, feature suggestion, and PR helps us build a better Preswald. Let’s create something amazing together! 🚀