Contributing¶
Thank you for your interest in contributing to mcup! We appreciate your help in making this project better. This guide will help you get started with setting up your development environment, making changes, and submitting a pull request.
Getting Started¶
Fork the Repository¶
First, create a fork of the mcup repository on GitHub. This gives you your own copy of the project to work on.
Clone Your Fork¶
Clone your forked repository to your local machine:
Set Up Development Environment¶
It is recommended to use a virtual environment to manage dependencies:
Install the project dependencies and the project itself in editable mode:
Project Structure¶
Here is a quick overview of the project's structure to help you navigate the codebase:
.github/: GitHub-related configuration files (workflows, issue templates).debian/: Files for building the.debpackage.mcup/: The main source code directory.mcup.core: Core application logic (handlers, utils, status codes).mcup.cli: Command-line interface code (commands, UI components).mcup.devtools: Development tools to assist with testing and maintenance.
rpm/: Files for building the.rpmpackage.docs/: Documentation files (MkDocs).
Running Locally¶
You can run the CLI directly from the source code to test your changes.
Using Entry Point (Recommended)¶
The easiest way to run the CLI is by using the installed mcup command within your virtual environment.
Since you installed the package in editable mode (pip install -e .), any changes you make to the code are immediately
reflected.
- Ensure your virtual environment is activated.
- Run the command:
Using Helper Scripts¶
We provide helper scripts that handle the execution for you, which can be useful if you haven't activated your virtual environment manually.
Using Python Module¶
Alternatively, you can run the package directly using Python:
Building the Project¶
To build the distributable packages (DEB, RPM), use the provided build script.
This will generate the packages in the dist directory.
Note
You can skip specific package builds using flags:
--skip-deb: Skip building the Debian package.--skip-rpm: Skip building the RPM package.
Commit Message Convention¶
We follow the Conventional Commits style to keep our commit history clear and easy to understand.
Each commit message should start with a type prefix, followed by a colon and a short description:
Common Types¶
| Type | Description | Example |
|---|---|---|
| feat | A new feature | feat: add support for YAML config loading |
| fix | A bug fix | fix: prevent crash when config file is missing |
| docs | Documentation only changes | docs: update usage section in README.md |
| style | Code style changes (formatting, etc) | style: reformat code with Black |
| refactor | Refactoring code without changing behavior | refactor: extract validation logic |
| test | Adding or updating tests | test: add unit tests for CLI argument parser |
| build | Changes to build scripts or dependencies | build: upgrade rich library |
| chore | Other changes | chore: update license year |
Optional Scope¶
You can optionally specify a scope in parentheses to indicate which part of the codebase is affected:
How to Write a Good Commit Message¶
- Keep the message concise (under 72 characters).
- Use the imperative mood ("fix bug" not "fixed bug").
- Explain what and why briefly.
Submitting a Pull Request¶
- Create a new branch for your feature or fix:
git checkout -b feat/my-new-feature. - Make your changes and test them locally.
- Commit your changes following the Commit Message Convention.
- Push your branch to your fork:
git push origin feat/my-new-feature. - Open a Pull Request on the main repository.
- Provide a clear description of your changes and why they are necessary.
We will review your PR and provide feedback. Thank you for contributing!