Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
185 lines (121 loc) · 5.44 KB

CONTRIBUTING.md

File metadata and controls

185 lines (121 loc) · 5.44 KB

Contributing

Contributions are welcome, and they are greatly appreciated! Every little bit helps, and credit will always be given.

You can contribute in many ways:

Types of Contributions

Report Bugs

Report bugs at https://github.com/tuttle-dev/tuttle/issues.

If you are reporting a bug, please include:

  • Your operating system name and version.
  • Any details about your local setup that might be helpful in troubleshooting.
  • Detailed steps to reproduce the bug.

Fix Bugs

Look through the GitHub issues for bugs. Anything tagged with "bug" and "help wanted" is open to whoever wants to implement it.

Implement Features

Look through the GitHub issues for features. Anything tagged with "enhancement" and "help wanted" is open to whoever wants to implement it.

Write Documentation

Tuttle could always use more documentation, whether as part of the official docs, in docstrings, or even on the web in blog posts, articles, and such.

Submit Feedback

The best way to send feedback is to file an issue at https://github.com/tuttle-dev/tuttle/issues.

If you are proposing a feature:

  • Explain in detail how it would work.
  • Keep the scope as narrow as possible, to make it easier to implement.
  • Remember that this is a volunteer-driven project, and that contributions are welcome :)

Get Started!

Ready to contribute? Here's how to set up Tuttle for local development.

  1. Fork the repo on GitHub.

  2. Clone your fork locally:

    git clone git@github.com:your_name_here/tuttle.git

  3. Install dependencies with uv:

    cd tuttle/
uv sync

  4. Create a branch for local development:

    git checkout -b name-of-your-bugfix-or-feature

    Now you can make your changes locally.

    Install the pre-commit hooks before making your first commit to ensure that you match the code style:

    pre-commit install

  5. If you haven't done so already, install and/or activate pyright. The "basic" level should suffice and help you to avoid type errors. If you are getting a type error, ask yourself: Can this occur at runtime?

    No -> add #type: ignore to the end of the line

    Yes -> ensure that it doesn't, e.g. by using an assert statement

    Oftentimes, type errors indicate bad design, so keep refactoring in mind as a third option.

  6. When you're done making changes, check that your changes pass the tests:

    uv run pytest

  7. Commit your changes and push your branch to GitHub:

    git add .
git commit -m "Your detailed description of your changes."
git push origin name-of-your-bugfix-or-feature

  8. Submit a pull request through the GitHub website.

Pull Request Guidelines

Before you submit a pull request, check that it meets these guidelines:

  1. The pull request should include tests.
  2. If the pull request adds functionality, the docs should be updated. Put your new functionality into a function with a docstring.
  3. The pull request should work for Python 3.12 and 3.13.

Tips

To run a subset of tests:

uv run pytest tuttle_tests/test_model.py

To run a specific test:

uv run pytest tuttle_tests/test_model.py::TestContract::test_valid_instantiation

Deploying

Make sure all your changes are committed. Then run:

bump2version patch  # possible: major / minor / patch
git push
git push --tags

Architecture Notes

The View

  • builds UI,
  • reacts to data changes (by updating the UI)
  • listens for events and forwards them to the Intent

The Intent

  • receives events
  • if some data is affected by the event, figure out which data source corresponds to that data
  • transforms the event data to the data format required by the data source
  • transform returned data source data to the data format required by the UI
  • else, no data is affected by the event, handle the event (often using a util class).
  • an example of this is sending invoices by mail.

The Model (a.k.a data layer)

  • defines the entity
  • define the entity source (file, remote API, local database, in-memory cache, etc)
  • if a relational database is used, define the entity's relationship to other entities
  • maintain the integrity of that relation (conflict strategies for insert operations are defined here, and integrity errors are thrown here, for example)
  • defines classes that manipulate this source (open, read, write, ....)

As you go outer in layers (the outmost layer is the UI, the innermost is the data layer), communication can occur downward across layers, and horizontally, BUT a layer cannot skip the layer directly below it. This is to say:

  • Data sources can communicate with each other. Thus ClientDatasource.delete_client can call ContractDatasource.get_contract for example.

  • Intents can communicate with each other, and with any data source. Thus ClientIntent can call ContractIntent or ContractDatasource for example. The UI can communicate with any intent (though often the UI is tied to only a single intent, and the intent can instead call the "other" intent). But it cannot communicate with a data source -- this would violate the do-not-skip-layers rule. An inner layer cannot have a dependency on the layer above it. Thus an intent cannot instantiate a UI class, and a data source cannot instantiate an Intent class.