ebump 0.2.2__tar.gz → 0.2.3__tar.gz

ebump-0.2.3/.env.test

@@ -0,0 +1 @@
+# ebump reads no environment variables; the test suite loads this file through pytest-env.

ebump-0.2.3/.github/workflows/qa.yml

@@ -0,0 +1,14 @@
+name: QA
+
+on:
+  pull_request:
+  push:
+    branches: [main]
+
+jobs:
+  qa:
+    uses: gvieralopez/cookie-pyrate/.github/workflows/reusable-qa.yml@v1.1.0
+    with:
+      cookie-pyrate-ref: v1.1.0
+      python-version: "3.11"
+      test-python-versions: '["3.12", "3.13", "3.14", "3.15"]'

ebump-0.2.3/.github/workflows/release.yml

@@ -0,0 +1,40 @@
+name: Release
+
+on:
+  workflow_run:
+    workflows: ["QA"]
+    branches: [main]
+    types: [completed]
+
+concurrency:
+  group: release
+  cancel-in-progress: false
+
+jobs:
+  release:
+    if: github.event.workflow_run.conclusion == 'success'
+    uses: gvieralopez/cookie-pyrate/.github/workflows/reusable-release.yml@v1.1.0
+    permissions:
+      contents: write
+    with:
+      cookie-pyrate-ref: v1.1.0
+      create-github-release: true
+      attach-distribution: false
+      prepare-next-version: true
+    secrets:
+      # Created by `make repo`; lets the version bumps land on a protected main.
+      RELEASE_SSH_KEY: ${{ secrets.RELEASE_SSH_KEY }}
+
+  pypi:
+    needs: release
+    runs-on: ubuntu-latest
+    environment:
+      name: pypi
+      url: https://pypi.org/project/ebump/
+    permissions:
+      contents: read
+      id-token: write
+    steps:
+      - uses: gvieralopez/cookie-pyrate/.github/actions/publish-to-pypi@v1.1.0
+        with:
+          sha: ${{ needs.release.outputs.sha }}

ebump-0.2.3/.gitignore

@@ -0,0 +1,220 @@
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[codz]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+share/python-wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+MANIFEST
+
+# PyInstaller
+#  Usually these files are written by a python script from a template
+#  before PyInstaller builds the exe, so as to inject date/other infos into it.
+*.manifest
+*.spec
+
+# Installer logs
+pip-log.txt
+pip-delete-this-directory.txt
+
+# Unit test / coverage reports
+htmlcov/
+.tox/
+.nox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+*.py.cover
+.hypothesis/
+.pytest_cache/
+cover/
+
+# Translations
+*.mo
+*.pot
+
+# Django stuff:
+*.log
+local_settings.py
+db.sqlite3
+db.sqlite3-journal
+
+# Flask stuff:
+instance/
+.webassets-cache
+
+# Scrapy stuff:
+.scrapy
+
+# Sphinx documentation
+docs/_build/
+
+# PyBuilder
+.pybuilder/
+target/
+
+# Jupyter Notebook
+.ipynb_checkpoints
+
+# IPython
+profile_default/
+ipython_config.py
+
+# pyenv
+#   For a library or package, you might want to ignore these files since the code is
+#   intended to run in multiple environments; otherwise, check them in:
+# .python-version
+
+# pipenv
+#   According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
+#   However, in case of collaboration, if having platform-specific dependencies or dependencies
+#   having no cross-platform support, pipenv may install dependencies that don't work, or not
+#   install all needed dependencies.
+#Pipfile.lock
+
+# UV
+#   Similar to Pipfile.lock, it is generally recommended to include uv.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+# uv.lock is intentionally committed for reproducible environments.
+
+# poetry
+#   Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+#   https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
+#poetry.lock
+#poetry.toml
+
+# pdm
+#   Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
+#   pdm recommends including project-wide configuration in pdm.toml, but excluding .pdm-python.
+#   https://pdm-project.org/en/latest/usage/project/#working-with-version-control
+#pdm.lock
+#pdm.toml
+.pdm-python
+.pdm-build/
+
+# pixi
+#   Similar to Pipfile.lock, it is generally recommended to include pixi.lock in version control.
+#pixi.lock
+#   Pixi creates a virtual environment in the .pixi directory, just like venv module creates one
+#   in the .venv directory. It is recommended not to include this directory in version control.
+.pixi
+
+# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
+__pypackages__/
+
+# Celery stuff
+celerybeat-schedule
+celerybeat.pid
+
+# Redis
+*.rdb
+*.aof
+*.pid
+
+# RabbitMQ
+mnesia/
+rabbitmq/
+rabbitmq-data/
+
+# ActiveMQ
+activemq-data/
+
+# SageMath parsed files
+*.sage.py
+
+# Environments
+.env
+.envrc
+.venv
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# Spyder project settings
+.spyderproject
+.spyproject
+
+# Rope project settings
+.ropeproject
+
+# mkdocs documentation
+/site
+
+# mypy
+.mypy_cache/
+.dmypy.json
+dmypy.json
+
+# Pyre type checker
+.pyre/
+
+# pytype static type analyzer
+.pytype/
+
+# Cython debug symbols
+cython_debug/
+
+# PyCharm
+#  JetBrains specific template is maintained in a separate JetBrains.gitignore that can
+#  be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
+#  and can be added to the global gitignore or merged into this file.  For a more nuclear
+#  option (not recommended) you can uncomment the following to ignore the entire idea folder.
+.idea/
+
+# Abstra
+# Abstra is an AI-powered process automation framework.
+# Ignore directories containing user credentials, local state, and settings.
+# Learn more at https://abstra.io/docs
+.abstra/
+
+# Visual Studio Code
+#  Visual Studio Code specific template is maintained in a separate VisualStudioCode.gitignore
+#  that can be found at https://github.com/github/gitignore/blob/main/Global/VisualStudioCode.gitignore
+#  and can be added to the global gitignore or merged into this file. However, if you prefer,
+#  you could uncomment the following to ignore the entire vscode folder
+.vscode/
+
+# Ruff stuff:
+.ruff_cache/
+
+# PyPI configuration file
+.pypirc
+
+# Marimo
+marimo/_static/
+marimo/_lsp/
+__marimo__/
+
+# Streamlit
+.streamlit/secrets.toml
+
+# Checkout of the shared Cookie Pyrate actions, made by the CI workflows in the
+# workspace root. It is a separate repository and is linted where it lives.
+.cookie-pyrate/

ebump-0.2.3/.pre-commit-config.yaml

@@ -0,0 +1,23 @@
+repos:
+  - repo: local
+    hooks:
+      - id: lint
+        name: Ruff Lint
+        entry: make lint
+        language: system
+        types: [python]
+        pass_filenames: false
+
+      - id: format
+        name: Ruff Format
+        entry: make format
+        language: system
+        types: [python]
+        pass_filenames: false
+
+      - id: typecheck
+        name: Mypy Typecheck
+        entry: make typecheck
+        language: system
+        types: [python]
+        pass_filenames: false

ebump-0.2.3/.python-version

@@ -0,0 +1 @@
+3.11

ebump-0.2.3/AGENTS.md

@@ -0,0 +1,47 @@
+# ebump
+
+Easy version bumping
+
+Style, conventions and tooling for this project.
+
+## Layout
+
+1. `src/ebump/{models,errors,main}.py`; sub-domains as sub-packages (e.g. `validation/`).
+2. Data structures live in `models.py`, error types in `errors.py`, unless the framework in use recommends a different file structure.
+3. Order functions top-down — callers before callees, private helpers (`_name`) last — so the most important read first.
+4. Do not write docstrings or descriptive comments unless the user asks for them or they provide context that cannot be inferred by reading the code.
+
+## Design
+
+1. Prefer immutable dataclasses for plain data: `@dataclass(frozen=True)` (add `slots=True` when it fits).
+2. Where a framework owns the type — ORM entities, pydantic models, settings objects — follow its idiom instead of forcing a dataclass.
+3. Avoid default arguments in functions.
+4. If a function takes a bool that drives an `if`, prefer splitting into two functions (one delegating to the other, or factoring out shared logic when it saves ≥2 LoC).
+
+## Hygiene
+
+1. No commented-out code.
+2. Every `# noqa` must specify a rule code, e.g. `# noqa: E501` and should be avoided unless the user asks for it.
+3. Serialise JSON with `indent=2`.
+4. Wrap any disk I/O in `TemporaryDirectory()` and operate via `Path` objects.
+
+## Python
+
+1. Always use f-strings, `pathlib`, and idiomatic constructs.
+2. Avoid `open()` for reading or writing — use `Path.read_text()` / `Path.write_text()` / `Path.read_bytes()` / `Path.write_bytes()` (ruff `PTH`).
+3. Never use `print` outside `scripts/`. Use `logger = logging.getLogger(__name__)` at module level (ruff `T20`).
+4. Annotate everything; mypy runs with `disallow_untyped_defs = true`. Use modern typing (`list[...]`, `dict[...]`, `X | None`, `collections.abc.MutableMapping`, etc.).
+
+## Tests
+
+1. Function-based pytest with `@pytest.mark.parametrize`. No test classes.
+2. The test tree mirrors the package tree: a module at `validation/rules.py` is tested by `tests/validation/test_rules.py`.
+3. Shared fixtures, env dicts and fixture-path constants live in `tests/conftest.py`. Test data under `tests/data/` or `tests/fixtures/`.
+4. `.env.test` holds the suite's baseline environment; `pytest-env` loads it before collection. Override a single variable in a single test with `monkeypatch.setenv` / `monkeypatch.delenv` — never assign to `os.environ` directly, so nothing leaks between tests.
+5. Don't lower the `--cov-fail-under` threshold configured in `pyproject.toml`; add tests instead.
+
+## Tooling
+
+1. Use **ruff + mypy + pytest** with **uv**.
+2. Standard QA invocation: `make qa` — it covers lint, format, type checks and tests. `make test` runs the suite on its own.
+3. Never call `python3` directly in agent scripts; use `uv run` so inline script metadata can declare dependencies.

ebump-0.2.3/CODEOWNERS

@@ -0,0 +1 @@
+* @jmorgadov @gvieralopez

ebump-0.2.3/DEVELOPMENT.md

@@ -0,0 +1,319 @@
+# Development Guide
+
+## Prerequisites
+
+Before developing this project, ensure you have the following installed:
+
+### [uv](https://docs.astral.sh/uv/)  
+Python project and environment management.  
+Install: [uv docs](https://docs.astral.sh/uv/getting-started/installation/)
+
+### [make](https://www.gnu.org/software/make/)  
+Run common project tasks via the `Makefile`.
+
+#### macOS  
+```sh
+xcode-select --install
+```
+
+#### Windows  
+```powershell
+choco install make
+```
+
+#### Linux
+Usually pre-installed. If not:
+```sh
+sudo apt install build-essential   # Debian/Ubuntu
+sudo dnf groupinstall "Development Tools"   # Fedora
+```
+
+### [git](https://git-scm.com/downloads)  
+Version control, and what `make repo` uses to initialise the repository.
+
+### [GitHub CLI](https://cli.github.com)  
+Lets `make repo` create the GitHub remote and apply the branch policies.  
+Authenticate once with `gh auth login`.
+
+
+## Installation in development mode
+
+Install all dependencies including development tools:
+
+```bash
+uv sync
+```
+
+This creates a `.venv` folder and installs the project and default development
+dependencies from `pyproject.toml` and the committed `uv.lock` file. After changing
+dependencies, use `uv add`/`uv remove`, then run `uv lock` and commit the lockfile.
+
+Activate the environment:
+
+* **Linux / macOS (bash/zsh):**
+  ```bash
+  source .venv/bin/activate
+  ```
+
+* **Windows (PowerShell):**
+  ```powershell
+  .venv\Scripts\Activate.ps1
+  ```
+
+* **Windows (cmd.exe):**
+  ```cmd
+  .venv\Scripts\activate.bat
+  ```
+
+## Development Tasks
+
+All tasks are defined in the `Makefile` for convenience.
+
+### Running the Full Quality Gate
+
+```bash
+make qa
+```
+
+Runs **Ruff** for linting and formatting, **Mypy** for type checking, and **Pytest** for
+the test suite. Each stage is also available on its own: `make lint`, `make format`,
+`make typecheck` and `make test`.
+
+### Running Unit Tests
+
+Before running tests, configure environment variables in `.env.test` if needed.
+
+```bash
+make test
+```
+
+Executes the test suite using **Pytest**, without the lint, format and type checks.
+
+### Creating the Repository
+
+Initialise the local repository and create its first commit on `main`:
+
+```bash
+make repo
+```
+
+The same command then creates the GitHub remote, pushes `main`, and applies the branch
+policies. The remote is private by default; to make it public:
+
+```bash
+make repo REPO_ARGS=--public
+```
+
+To create it under an organization instead of your own account:
+
+```bash
+make repo REPO_ARGS="--owner my-org"
+```
+
+The README's badges link to your own account; for an organization, replace your username with
+the organization in those links.
+
+`main` is protected: changes land through pull requests, merged with a merge commit, once all
+review conversations are resolved, the branch is up to date with `main`, and the `qa / Run QA`
+check is green. No approval is required, except a code owner's when the project has a
+`CODEOWNERS` file; new pushes dismiss earlier approvals. Force pushes and branch deletion are
+rejected. Repository admins and the release deploy key can bypass these rules; the key is how
+the release workflow pushes its version bumps.
+
+Branch rulesets are a paid GitHub feature on private repositories. On a free plan the
+command says so, leaves `main` unprotected and finishes the rest; make the repository
+public or upgrade the plan, then re-run `make repo` to apply the policies.
+
+It also turns on Dependabot alerts and security updates: when a version pinned in `uv.lock`
+has a published advisory, Dependabot opens a pull request that moves it to a fixed version.
+Routine version updates stay off, since every merge to `main` cuts a release.
+
+The local steps need only git; the remote ones need the
+[GitHub CLI](https://cli.github.com) authenticated with `gh auth login`. Without it the
+local repository is still created and nothing is pushed.
+
+The command is safe to re-run: each step is skipped if it is already done, so an
+interrupted run can be finished by running it again.
+
+### Migrating to Git Worktrees
+
+Migrate the repository to a shared bare-repository layout:
+
+```bash
+make worktree
+```
+
+This creates `.bare` for the shared Git history and a directory for the current
+branch. If the current branch is not the remote default branch, a second directory
+is created for that default branch. The converted repository root contains only
+`.bare`, the `.git` pointer, and the worktree directories. Before converting, it
+copies the complete original repository, including `.git`, to a sibling directory
+named `<repo-name>-legacy-bak`, restores the original files to the current branch
+worktree, and refuses to overwrite an existing backup or worktree layout. If the
+migration fails, the original repository is restored and the temporary backup is
+removed.
+
+### Building the Project
+
+```bash
+make build
+```
+
+Generates a distribution package in the `dist/` directory.
+
+### Releasing
+
+Every push to `main` that passes QA cuts a release: the version is finalized,
+tagged, and `main` is bumped to the next prerelease. You can control the release
+process with the following options on the `.github/workflows/release.yml` workflow:
+
+- `create-github-release` (on by default) — cuts a GitHub release for the new tag.
+- `attach-distribution` (off by default) — builds the distribution and attaches it to the
+  GitHub release as downloadable files. Requires `create-github-release` to also be on.
+- `prepare-next-version` (on by default) — bumps `main` to the next prerelease once the
+  release is out.
+
+#### Publishing to PyPI
+
+Set up Trusted Publishing so no API token has to be stored as a secret:
+
+1. Go to <https://pypi.org/manage/account/publishing/> (for a project already on PyPI, its own
+   "Publishing" settings)
+2. Add a GitHub publisher with this repository, the workflow name `release.yml` and the
+   environment name `pypi`
+3. Save. PyPI will now trust publish requests coming from that workflow.
+
+Then add a `pypi` job to `.github/workflows/release.yml`, next to the `release` job:
+
+```yaml
+  pypi:
+    needs: release
+    runs-on: ubuntu-latest
+    environment:
+      name: pypi
+      url: https://pypi.org/project/ebump/
+    permissions:
+      contents: read
+      id-token: write
+    steps:
+      - uses: gvieralopez/cookie-pyrate/.github/actions/publish-to-pypi@v1.1.0
+        with:
+          sha: ${{ needs.release.outputs.sha }}
+```
+
+The job has to live in this file: PyPI only trusts the workflow file that defines the uploading
+job, so the upload can't happen inside the reusable release. The action builds the released
+commit and uploads it. It runs once the release is out, so if the upload fails the GitHub release
+is already published: re-run the failed `pypi` job; files PyPI already has are skipped.
+
+To try it on TestPyPI first, register the publisher on <https://test.pypi.org> instead and add
+`index: testpypi` under `with:`. A build that needs `system-dependencies` or a `setup-command`
+takes them under `with:` too; secrets the setup command needs go in the step's `env:`.
+
+#### Extra release files
+
+Files the reusable release doesn't build (executables, wheels compiled per OS, PDFs, archives)
+come from jobs you add to `.github/workflows/release.yml`, after the `release` job. It hands them
+the released `version`, `tag` and `sha`, so they build exactly the released commit and attach to
+exactly that release:
+
+```yaml
+  windows-exe:
+    needs: release
+    runs-on: windows-latest
+    permissions:
+      contents: write
+    steps:
+      - uses: actions/checkout@v7
+        with:
+          ref: ${{ needs.release.outputs.sha }}
+      # ...build the files into dist/...
+      - uses: softprops/action-gh-release@v3
+        with:
+          tag_name: ${{ needs.release.outputs.tag }}
+          files: dist/*.exe
+```
+
+The release is already published when these jobs start, so its extra files appear a few
+minutes later.
+
+### Extra CI steps
+
+The reusable workflows take two optional inputs for what lint, types and tests don't cover.
+Add them under `with:` in `.github/workflows/qa.yml` (`setup-command` also in `release.yml`):
+
+- `setup-command`: bash run before the dependencies are installed, for files the install needs,
+  such as the wheels of a private dependency. In releases it also runs before the distribution
+  and the Docker image are built.
+- `extra-checks`: bash run after the tests; a failure fails QA. For example import contracts
+  (`uv run lint-imports`) or a strict docs build.
+
+A setup command that needs secrets gets them through the `SETUP_ENV` secret: `NAME=value`
+lines, one per variable, that the calling job builds from the repository's own secrets. Each
+value is masked in the logs and set as an environment variable for the setup command only; the
+install, checks, tests and builds that follow don't see it. Values are single lines.
+`secrets: inherit` doesn't work here: GitHub only passes inherited secrets to workflows of the
+same account or organization, and these live in `gvieralopez/cookie-pyrate`. The secrets you
+pass run through Cookie Pyrate's code at the version you pin.
+
+Dependabot's pull requests only get Dependabot secrets, so a secret QA needs must also be added
+as a Dependabot secret (`gh secret set NAME --app dependabot`), or its security fixes fail QA.
+In an organization, set it once as an organization secret for both Actions and Dependabot.
+
+```yaml
+jobs:
+  qa:
+    uses: gvieralopez/cookie-pyrate/.github/workflows/reusable-qa.yml@v1.1.0
+    with:
+      cookie-pyrate-ref: v1.1.0
+      python-version: "3.11"
+      setup-command: uv run --no-project --with requests scripts/download_wheels.py
+      extra-checks: |
+        uv run lint-imports
+    secrets:
+      SETUP_ENV: |
+        WHEELS_TOKEN=${{ secrets.WHEELS_TOKEN }}
+```
+
+In `release.yml`, add `SETUP_ENV` next to `RELEASE_SSH_KEY` under `secrets:`.
+
+Commands run with `bash -eo pipefail`, on Windows runners too, and stop at the first failure.
+
+### Cleaning Up
+
+```bash
+make clean
+```
+
+Removes build artifacts, caches, and temporary files.
+
+
+
+
+
+
+## Pre-Commit Hooks
+
+This project uses [pre-commit](https://pre-commit.com/) to run code quality checks automatically before each commit.
+
+### Setup
+
+Install the hooks:
+
+```bash
+make repo  # if you haven't already
+uv run pre-commit install
+```
+
+Checks will now run automatically on every commit.
+
+### Manual Execution
+
+Trigger all hooks manually:
+
+```bash
+uv run pre-commit run --all-files
+```
+
+This runs the same lint, format and type checks as `make qa`, without the tests.
+