Hi there! Thank you for even being interested in contributing to wasm_exec. As an open source project, we are extremely open to contributions, whether they be in the form of new features, improved infra, better documentation, or bug fixes.
To contribute to this project, please follow a "fork and pull request" workflow. Please do not try to push directly to this repo unless you are maintainer.
Please follow the checked-in pull request template when opening pull requests. Note related issues and tag relevant maintainers.
Pull requests cannot land without passing the formatting, linting and testing checks first. See Common Tasks for how to run these checks locally.
It's essential that we maintain great documentation and testing. If you:
- Fix a bug
- Add a relevant unit or integration test when possible. These live in
tests.
- Add a relevant unit or integration test when possible. These live in
Our issues page is kept up to date with bugs, improvements, and feature requests.
If you start working on an issue, please assign it to yourself.
If you are adding an issue, please try to keep it focused on a single, modular bug/improvement/feature. If two issues are related, or blocking, please link them rather than combining them.
We will try to keep these issues as up to date as possible, though with the rapid rate of develop in this field some may get out of date. If you notice this happening, please let us know.
Our goal is to have the simplest developer setup possible. Should you experience any difficulty getting setup, please contact a maintainer! Not only do we want to help get you unblocked, but we also want to make sure that the process is smooth for future contributors.
In a similar vein, we do enforce certain linting, formatting, and documentation standards in the codebase. If you are finding these difficult (or even just annoying) to work with, feel free to contact a maintainer for help - we do not want these to get in the way of getting good code into the codebase.
This project uses Poetry as a dependency manager. Check out Poetry's documentation on how to install it on your system before proceeding.
❗Note: If you use Conda or Pyenv as your environment / package manager, avoid dependency conflicts by doing the following first:
- Before installing Poetry, create and activate a new Conda env (e.g.
conda create -n langchain python=3.9) - Install Poetry (see above)
- Tell Poetry to use the virtualenv python environment (
poetry config virtualenvs.prefer-active-python true) - Continue with the following steps.
To install requirements:
poetry install --all-extrasThis will install all requirements for running the package, examples, linting, formatting, tests, and coverage. Note the --all-extras flag will install all optional dependencies necessary for integration testing.
❗Note: If you're running Poetry 1.4.1 and receive a WheelFileValidationError for debugpy during installation, you can try either downgrading to Poetry 1.4.0 or disabling "modern installation" (poetry config installer.modern-installation false) and re-install requirements. See this debugpy issue for more details.
Now, you should be able to run the common tasks in the following section. To double check, run make test, all tests should pass.
Type make for a list of common tasks.
Formatting for this project is done via a combination of Black and isort.
To run formatting for this project:
make formatLinting for this project is done via a combination of Black, isort, flake8, and mypy.
To run linting for this project:
make lintWe recognize linting can be annoying - if you do not want to do it, please contact a project maintainer, and they can help you with it. We do not want this to be a blocker for good code getting contributed.
Code coverage (i.e. the amount of code that is covered by unit tests) helps identify areas of the code that are potentially more or less brittle.
To get a report of current coverage, run the following:
make coverageUnit tests cover modular logic that does not require calls to outside APIs.
To run unit tests:
make testIf you add new logic, please add a unit test.
Right now, documentation is via docstrings and the README. In the future we will be adding docs that are autogenerated by sphinx, so please follow the sphinx docstring format.
As of now, wasm_exec has an ad hoc release process: releases are cut with high frequency by a developer and published to PyPI.
wasm_exec follows the semver versioning standard. However, as pre-1.0 software, even patch releases may contain non-backwards-compatible changes.