Skip to content

chore: use jython template#314

Merged
cesarcoatl merged 2 commits intomainfrom
chore/ignition-devs-copier-templates-jython
Apr 15, 2026
Merged

chore: use jython template#314
cesarcoatl merged 2 commits intomainfrom
chore/ignition-devs-copier-templates-jython

Conversation

@cesarcoatl
Copy link
Copy Markdown
Member

@cesarcoatl cesarcoatl commented Apr 15, 2026

from ignition-devs/copier-templates

Summary by Sourcery

Align project configuration and workflows with the shared jython copier template and refresh project metadata.

New Features:

  • Add a reusable Jython CI job that installs and tests the package using a cached Jython environment.
  • Introduce separate tox jobs for the main package and stubs across supported Python versions in CI and publish workflows.

Enhancements:

  • Adopt shared reusable GitHub workflows for pre-commit, pylint, tox, and PyPI publishing, replacing local workflow definitions.
  • Simplify and rename Makefile installation targets for Jython-based installs to a consistent install-* naming scheme.
  • Update package and stubs metadata, descriptions, keywords, URLs, and copyright years to match the current project branding and template.
  • Tighten mypy configuration for stubs and adjust Sourcery config and ignores to match the common template.
  • Streamline tox and pre-commit configs by removing local style/typecheck environments now handled by shared tooling.

Documentation:

  • Refresh README content for the main package and stubs to use the new standardized project description and trim contributor/community sections from the stubs README.

from ignition-devs/copier-templates
@sourcery-ai
Copy link
Copy Markdown
Contributor

sourcery-ai Bot commented Apr 15, 2026

Reviewer's Guide

Aligns the project with the ignition-devs jython copier template by restructuring CI/publish workflows, simplifying tox/pre-commit/stubs configs, updating packaging/metadata, and standardizing Jython install targets and documentation text.

Sequence diagram for CI pipeline on pull_request

sequenceDiagram
    actor Dev
    participant GitHub as GitHub_Actions
    participant CI as Workflow_ci_yml
    participant PreCommit as Job_pre-commit
    participant Pylint as Job_pylint
    participant Jython as Job_jython
    participant ToxPkg as Job_tox-package
    participant ToxStubs as Job_tox-stubs

    Dev->>GitHub: open_or_update_pull_request
    GitHub->>CI: trigger_ci_workflow

    CI->>PreCommit: start_reusable_pre-commit
    PreCommit-->>CI: pre-commit_finished

    CI->>Pylint: start_reusable_pylint(needs pre-commit)
    Pylint-->>CI: pylint_finished

    CI->>Jython: start_inline_jython_job
    Jython->>Jython: checkout_repository
    Jython->>Jython: setup_jython_2_7_3
    Jython->>Jython: cache_JYTHON_CACHE_DIR
    Jython->>Jython: make_install_with_cache
    Jython-->>CI: jython_installation_ok

    CI->>ToxPkg: start_reusable_tox-docker
    ToxPkg-->>CI: tox_docker_finished

    CI->>ToxStubs: start_reusable_tox_stubs
    ToxStubs-->>CI: tox_stubs_finished

    CI-->>GitHub: report_job_statuses
    GitHub-->>Dev: checks_pass_or_fail
Loading

Flow diagram for updated Jython Makefile install targets

flowchart TD
  Dev[Developer] --> ChooseTarget{Select make target}

  ChooseTarget --> TInstall[make install]
  ChooseTarget --> TInstallClean[make install-clean]
  ChooseTarget --> TInstallForce[make install-force]
  ChooseTarget --> TInstallNoCache[make install-nocache]
  ChooseTarget --> TInstallNoDeps[make install-nodeps]

  subgraph Common_Steps
    direction TB
    Step_Check[check]
    Step_Init[init]
  end

  TInstall --> Step_Check
  TInstall --> Step_Init
  Step_Init --> InstallCache[Run jython -m pip install --cache-dir JYTHON_CACHE_DIR .]

  TInstallClean --> Step_Check
  TInstallClean --> Step_Init
  TInstallClean --> Clean[clean]
  Clean --> InstallCacheClean[Run jython -m pip install --cache-dir JYTHON_CACHE_DIR .]

  TInstallForce --> Step_Check
  TInstallForce --> Step_Init
  Step_Init --> InstallForce[Run jython -m pip install --force-reinstall --cache-dir JYTHON_CACHE_DIR .]

  TInstallNoCache --> Step_Check
  Step_Check --> InstallNoCache[Run jython -m pip install --no-cache-dir .]

  TInstallNoDeps --> Step_Check
  Step_Check --> InstallNoDeps[Run jython -m pip install --no-deps .]
Loading

File-Level Changes

Change Details Files
Restructure CI workflow to use shared organization workflows and inline Jython job, plus add pre-commit and separate tox jobs for package and stubs.
  • Add workflow_dispatch trigger and new pre-commit job using coatl-dev reusable workflow with pylint skipped.
  • Update pylint job to depend on pre-commit and remove custom path input.
  • Replace reusable jython workflow with an inline job that sets up Jython, caches its installation, and runs make install.
  • Split tox job into tox-package (docker-based) and tox-stubs jobs that run only on pull_request and configure stubs tox to run under multiple Python versions from stubs directory.
.github/workflows/ci.yml
Rework publish workflow to run package and stubs tox via shared workflows and configure PyPI uploads with template-compatible job/secret names.
  • Replace local tox workflow usage with tox-docker and tox workflows to validate package and stubs, respectively.
  • Split publish into pypi-publish-package and pypi-publish-stubs jobs with explicit needs dependencies.
  • Configure PyPI upload jobs with explicit python-version, URL, username, working-directory for stubs, and a unified secret name for the PyPI token.
.github/workflows/publish.yml
Simplify tox configuration by removing unused environments and aligning stubs tox with template expectations.
  • Remove pip-compile and style environments from top-level tox.ini, keeping only stubgen and formatting config.
  • In stubs/tox.ini, lower required tox version, drop typecheck/style/parallell gh mapping, and define a py312 env that runs mypy over stubs using custom mypy fork; keep flake8/isort settings with adjusted ignores.
tox.ini
stubs/tox.ini
Align stubs package metadata, README, and license with the jython template and new project positioning.
  • Rewrite stubs README intro and installation text to describe incendium more generically, remove contribution/discussion/license sections, and drop unused reference links.
  • Reset stubs package version to 0.0.1, adjust description/keywords, relax ignition-api-stubs version pin, add Homepage URL, and convert setuptools package-data config to the new table syntax.
  • Add LICENSE file under stubs/ to support publishing the stubs package independently.
stubs/README.md
stubs/pyproject.toml
stubs/LICENSE
Update pre-commit, Sourcery, and mypy configs to match template defaults.
  • Remove pre-commit CI autofix/autoupdate configuration, rename hook IDs for clarity (package vs stubs), tweak language_version placement, and pin commitizen to v4.13.9.
  • Normalize .sourcery.yaml indentation, extend ignore paths, set python_version with single quotes, add empty rules section, and configure proxy.no_ssl_verify.
  • Tighten mypy settings by adding strict to stubs/.mypy.ini and ensuring root .mypy.ini ends with newline.
.pre-commit-config.yaml
.sourcery.yaml
.mypy.ini
stubs/.mypy.ini
Standardize project metadata and documentation strings to the new description and copyright year.
  • Simplify top-level README and package/module docstrings to the new one-line description for incendium and its stubs.
  • Update about.copyright year to 2018-2026.
  • Adjust setup.py module docstring and keywords to match the new description and branding.
README.md
src/incendium/__init__.py
src/incendium/__about__.py
setup.py
Refactor Makefile install targets to a consistent naming scheme used by the template.
  • Rename cleaninstall/forceinstall/nocacheinstall/nodepsinstall targets to install-clean/install-force/install-nocache/install-nodeps, preserving behaviors and help text.
  • Update PHONY declarations accordingly to match the new target names.
Makefile
Introduce copier template metadata file and remove now-obsolete local workflows.
  • Add .copier-answers.yml capturing template inputs such as project metadata, registry config, and jython project type.
  • Delete legacy .github/workflows/jython.yml and tox.yml which are replaced by shared workflows and inline Jython job.
  • Touch or regenerate various root config files (.devcontainer.json, .editorconfig, .gitignore, LICENSE) as part of template application (no substantive changes shown in diff).
.copier-answers.yml
.github/workflows/jython.yml
.github/workflows/tox.yml
.devcontainer.json
.editorconfig
.gitignore
LICENSE

Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

Copy link
Copy Markdown
Contributor

@sourcery-ai sourcery-ai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey - I've found 4 issues, and left some high level feedback:

  • In .github/workflows/publish.yml, both tox-package and tox-stubs are gated with if: ${{ github.event_name == 'pull_request' }} even though the workflow only triggers on release events, so these jobs (and the dependent PyPI publish jobs) will never run; drop the pull_request condition or adjust it to match the release trigger.
Prompt for AI Agents
Please address the comments from this code review:

## Overall Comments
- In `.github/workflows/publish.yml`, both `tox-package` and `tox-stubs` are gated with `if: ${{ github.event_name == 'pull_request' }}` even though the workflow only triggers on `release` events, so these jobs (and the dependent PyPI publish jobs) will never run; drop the `pull_request` condition or adjust it to match the release trigger.

## Individual Comments

### Comment 1
<location path=".github/workflows/publish.yml" line_range="9-10" />
<code_context>
+        run: |
+          make install JYTHON_CACHE_DIR=${{ env.JYTHON_CACHE_DIR }}
+
+  tox-package:
+    if: ${{ github.event_name == 'pull_request' }}
+    uses: coatl-dev/workflows/.github/workflows/tox-docker.yml@v6
+
</code_context>
<issue_to_address>
**issue (bug_risk):** Using `if: github.event_name == 'pull_request'` in a release-triggered workflow means `tox-package` (and thus publish jobs that depend on it) will never run.

Because this workflow only runs on `release` events, the `tox-package` and `tox-stubs` jobs are always skipped due to `if: ${{ github.event_name == 'pull_request' }}`. That means `pypi-publish-package` and `pypi-publish-stubs` (which depend on those jobs) can never succeed. Please either remove these `if` conditions or update them to match the `release` event so the publish stage runs on release creation.
</issue_to_address>

### Comment 2
<location path="stubs/tox.ini" line_range="4-5" />
<code_context>
 requires =
-    tox>=4.25
+    tox>=4.2
 env_list =
-    typecheck
     py3{9-12}
 skip_missing_interpreters = true
</code_context>
<issue_to_address>
**suggestion (testing):** The `env_list` includes py39–py312, but only `py312` is explicitly configured, which may run unexpected default environments.

With `env_list = py3{9-12}` and only `[testenv:py312]` defined, tox will run `py39`, `py310`, and `py311` using the implicit `[testenv]` (which you haven’t configured). Those envs may effectively “do nothing” or diverge from `py312` behavior. If you only need 3.12, consider restricting `env_list` to `py312`; otherwise, add explicit sections or a shared `[testenv]` so all Python versions run the same checks.
</issue_to_address>

### Comment 3
<location path="stubs/README.md" line_range="15-16" />
<code_context>

-To use `incendium-stubs`, you may install it with `pip`. It requires Python 3.9
-through 3.12.
+To use incendium, you may install it with `pip`. It requires Python
+3.9 - 3.12.

</code_context>
<issue_to_address>
**issue (typo):** The package name here should likely be "incendium-stubs" to match the project and install command.

Since this README and the install command both reference `incendium-stubs`, updating this line to use the same package name would avoid confusion.

```suggestion
To use `incendium-stubs`, you may install it with `pip`. It requires Python 3.9 through 3.12.
```
</issue_to_address>

### Comment 4
<location path="README.md" line_range="11" />
<code_context>
 [![Join us on GitHub discussions](https://img.shields.io/badge/github-discussions-informational)](https://github.com/orgs/ignition-devs/discussions)

-Package that extends and wraps some functions from Ignition's Scripting API.
+Package that extends and wraps Ignition Scripting API.

 For more information, please refer to the [Wiki].
</code_context>
<issue_to_address>
**nitpick (typo):** Consider adding "the" before "Ignition Scripting API" for smoother grammar.

Suggestion: change this to “Package that extends and wraps the Ignition Scripting API.” to make the sentence grammatically complete.

```suggestion
Package that extends and wraps the Ignition Scripting API.
```
</issue_to_address>

Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

Comment thread .github/workflows/publish.yml Outdated
Comment thread stubs/tox.ini
Comment on lines 4 to 5
env_list =
typecheck
py3{9-12}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion (testing): The env_list includes py39–py312, but only py312 is explicitly configured, which may run unexpected default environments.

With env_list = py3{9-12} and only [testenv:py312] defined, tox will run py39, py310, and py311 using the implicit [testenv] (which you haven’t configured). Those envs may effectively “do nothing” or diverge from py312 behavior. If you only need 3.12, consider restricting env_list to py312; otherwise, add explicit sections or a shared [testenv] so all Python versions run the same checks.

Comment thread stubs/README.md Outdated
Comment thread README.md Outdated
@cesarcoatl cesarcoatl merged commit 1e7dd80 into main Apr 15, 2026
6 checks passed
@cesarcoatl cesarcoatl deleted the chore/ignition-devs-copier-templates-jython branch April 15, 2026 21:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant