Changelog

[0.31.0] - 2026-08-23

Added:

  • Dedicated [format] configuration section in scaldys-project.toml with the markdown_targets setting, enabling explicit configuration of Markdown files and directories formatted by mdformat (directories are recursively scanned for *.md). Setting markdown_targets = [] explicitly disables Markdown formatting.

  • CI workflow drift detection: scaldys-project ci markdown inspects .github/workflows/ci.yml (if present) and logs a warning when workflow mdformat arguments diverge from the configured markdown_targets.

Changed:

  • scaldys-project format markdown and scaldys-project ci markdown now resolve target paths from [format] markdown_targets in scaldys-project.toml, falling back to default discovery (README.md and MkDocs doc directories) when unconfigured.

Docs:

  • Updated users/topics/configuration.rst and users/topics/scaldys_project_toml_reference.rst to document the [format] section and markdown_targets setting.

  • Updated developers/markdown_formatting.rst with target path resolution details and CI workflow drift detection guidance.

[0.30.0] - 2026-08-20

Changed:

  • Replaced the Node.js-based prettier markdown formatter and pre-commit framework with mdformat, a pure-Python CommonMark formatter invoked directly via uv run mdformat.

  • Scoped Markdown CI checks and formatting: scaldys-project ci markdown and scaldys-project format markdown now target README.md (in the project root) and all *.md files under MkDocs documentation directories (docs/**), explicitly excluding RELEASES.md and non-documentation Markdown files.

  • Updated GitHub Actions CI workflow (.github/workflows/ci.yml) to verify Markdown formatting directly via uv run mdformat --check README.md.

  • Updated pyproject.toml dev dependencies to include mdformat>=0.7.22 and removed pre-commit.

Removed:

  • Removed .pre-commit-config.yaml, .prettierrc, and the bundled resource src/scaldys_project/resources/.pre-commit-check-config.yaml.

  • Removed licenses/pre_commit.md.

Docs:

  • Rewrote developers/markdown_formatting.rst to document direct mdformat execution, CommonMark compliance, target scoping, and developer workflows.

  • Updated users/cli_usage.rst, developers/contributing.rst, and developers/publishing.rst with mdformat command syntax and descriptions.

  • Added licenses/mdformat.md (MIT License) and updated licenses/README.md.

[0.20.0] - 2026-08-05

Changed:

  • Simplified PyInstaller hook handling: the automatic renaming of hook_package.py to hook-<package_name>.py has been removed. Hook files must now be named correctly (hook-<package_name>.py) directly in the project source tree.

    Note

    Breaking change for consuming projects. Existing projects must rename their src/extra_hooks/hook_package.py to src/extra_hooks/hook-<package_name>.py (e.g. hook-scaldys_template.py) to remain compatible with scaldys-project >= 0.20.0.

Docs:

  • Updated users/topics/windows_exe.rst to instruct developers to use the hook-<package_name>.py naming convention directly.

[0.15.0] - 2026-07-31

Added:

  • Log the complete subprocess syntax to the terminal when executing CI, format, and test commands.

  • New compliance rule: Cython-compiled modules must not use match/case (PEP 634) syntax. Cython does not yet fully support this syntax, so scaldys-project now validates all modules listed in compiled_modules before starting the build. If any match/case blocks are detected, the compliance check reports a failure:

    ✗ match/case is not fully supported yet in cython. Replace it with an equivalent if-elif-else structure. Concerned files: src/myapp/engine.py

    The rule applies whenever compiled_modules in scaldys-project.toml is not empty.

Changed:

  • ci all and format all now execute all steps regardless of failures, providing a summary report at the end.

  • Minor improvements to terminal output readability.

Docs:

  • Updated CLI usage and developer guides to reflect command logging and the non-interrupting behavior of ci all and format all.

  • users/topics/compliance_checking.rst — Rule 12 added to the compliance table; mode-condition notes updated.

  • users/topics/cython_compilation.rst — Limitations and caveats updated to document the match/case limitation.

  • users/topics/scaldys_project_toml_reference.rst — Added a note to the compiled_modules setting regarding match/case.

  • users/topics/configuration.rst — Added a note to the compiled_modules description.

[0.14.0] - 2026-05-20

Added:

  • New compliance rule: tests/ directory must exist at the project root. scaldys-project check (and every build command that runs compliance checks) now reports a failure if the directory is absent:

    ✗ Tests directory not found: 'tests/'. Create it and add at least one test file.

    The rule is unconditional — it applies in all deployment modes. The tests/ directory is already where scaldys-project test (via [tool.pytest.ini_options] testpaths) looks for tests, so a missing directory would cause the test command to silently collect nothing. The check makes that failure explicit and early.

Changed:

  • scaldys-project init wizard — contextual hints are now printed above each prompt so users understand what to enter without consulting the manual. Every prompt in the four-section wizard gains a short dim/italic line that covers:

    • Project name — single word preferred; multi-word: lowercase with dashes (e.g. my-cool-app); underscores allowed but not recommended.

    • Package name — underscores only, dashes forbidden (e.g. my_cool_app); used in src/ layout and import statements.

    • Project slug — lowercase with dashes only, underscores forbidden (e.g. my-cool-app); used as git repo name and CLI entry-point.

    • Organization name — used in copyright notices and package metadata.

    • Author name / email — written to pyproject.toml and Sphinx docs.

    • Short description — one-line summary (≤ 80 chars) for pyproject.toml and README.

    • Initial version — semantic version MAJOR.MINOR.PATCH, stored in pyproject.toml.

    • GitHub username/org — used to generate badge URLs in README; leave empty to skip.

    • Deployment mode — inline legend listing what each of the three modes (pyinstaller, pyruntime, wheel_only) produces.

    • Target directory — where the project folder is created.

    • Initialise git repository? — runs git init + initial commit.

    • Run uv sync? — creates .venv and installs all dependencies.

Fixed:

  • --template-ref default documented as master in the changelog entry for 0.13.0 and in both cli_usage.rst and project_initialization.rst; corrected to main (matches the actual code default).

Docs:

  • users/topics/project_initialization.rst — Project identity wizard table updated: Project name notes now state the naming convention (single word preferred, multi-word → lowercase with dashes); Package name notes explicitly state dashes are forbidden and the field is used in src/ layout and imports; Project slug notes explicitly state underscores are forbidden. --template-ref default corrected to main.

  • users/cli_usage.rst — --template-ref default corrected to main.

  • users/topics/compliance_checking.rst — Rule 11 added to the compliance table; mode-condition notes updated.

  • users/topics/project_layout.rst — tests/ annotated as required in the recommended layout diagram; new Tests directory section added.

[0.13.0] - 2026-05-20

Added:

  • scaldys-project init — new interactive project-scaffolding command. Downloads scaldys-template from GitHub (or uses a local copy via --local PATH) and produces a fully configured project directory in one step.

    An interactive wizard collects project name, package name, project slug, organisation name, author details, description, version, GitHub username, Windows deployment mode, and target directory. A summary panel is shown before any files are written.

    After copying the template the command performs, in order:

    1. String replacement of all placeholder tokens in text files (Scaldys-Template, scaldys_template, scaldys-template, scaldys@scaldys.net, Scaldys; see Placeholder substitution in the user guide for the full ordered list).

    2. Post-order rename of every file and directory whose name contains a placeholder token.

    3. Targeted post-processing: copyright year and author in Sphinx conf.py files, description and initial version in pyproject.toml, deployment mode in scaldys-project.toml.

    4. Optional git init + initial commit.

    5. Optional uv sync to install project dependencies.

    Options: --local PATH, --template-ref REF (default: master), --force / -f, --no-git, --no-sync.

    No new package dependencies are required; all file operations use the Python standard library.

  • scaldys-project ci doclint — new RST documentation lint step that runs uv run sphinx-lint docs/ in the current directory. Reports RST style and syntax issues; exits non-zero if any are found. No files are modified. Included as the final step of ci all, mirroring the new Sphinx doc lint step added to the GitHub Actions ci.yml workflow.

  • sphinx-lint added to the project dev dependencies.

Fixed:

  • README.md (or whichever file is declared as readme in pyproject.toml) is now copied into build/compiled/ alongside pyproject.toml before the wheel is built, so PyPI receives the package description instead of showing “The author of this package has not provided a project description”.

Docs:

  • users/topics/project_initialization.rst (new) — full user guide for scaldys-project init: interactive wizard reference, substitution map, excluded items table, --local / --force usage, uv run tip, and CLI options reference.

  • developers/init_command.rst (new) — developer internals for cmd_init.py: module structure, template acquisition, exclusion list, replacement ordering rationale, binary file detection, post-order rename algorithm, targeted post-processing details, error handling, and an extension guide.

  • users/quickstart.rst — restructured into two paths: Starting a new project (using init) and Adding to an existing project (original content).

  • users/cli_usage.rst — init added to the command tree; new init reference section added with options table.

  • users/topics/index.rst — project_initialization added to the toctree and guide summaries.

  • developers/architecture.rst — cmd_init.py added to the module layout diagram; cross-reference to init_command_internals added.

  • users/overview.rst — Getting started quickly section updated to mention scaldys-project init as the bootstrap command.

  • cli_usage.rst — doclint added to the ci command tree; step 5 (RST documentation lint) added to the ci all step list; new ci doclint reference section added; step descriptions for ci all updated to use Python lint and Python type checking wording.

  • contributing.rst — scaldys-project ci doclint added to the ci command list with an inline annotation.

  • windows_exe.rst — How the wheel is built section updated to document that the readme file is copied into build/compiled/.

[0.12.0] - 2026-05-19

Added:

  • scaldys-project ci markdown — check-only Markdown formatting check that mirrors the Prettier format step in the GitHub Actions CI pipeline. Prettier runs in --check mode so no files are modified. Included as the final step of ci all.

    The check-only pre-commit configuration is bundled inside the scaldys-project wheel (scaldys_project/resources/.pre-commit-check-config.yaml) and resolved via importlib.resources at runtime. Consumer projects do not need a .pre-commit-check-config.yaml file in their root.

  • scaldys-project format — new command group for auto-formatting files in place:

    • format python — rewrites Python source files with uv run ruff format .

    • format markdown — rewrites Markdown files with uv run pre-commit run prettier --all-files

    • format all — runs format python then format markdown

  • scaldys_project/resources/.pre-commit-check-config.yaml — check-only pre-commit configuration (Prettier with --check) bundled as a package resource inside the wheel. Used exclusively by ci markdown; consumer projects are not required to provide this file.

Changed:

  • Configuration file renamed from scaldys.toml to scaldys-project.toml.

    The file name now unambiguously identifies which tool owns it within the scaldys project umbrella. Using just scaldys.toml was ambiguous when a consuming project also uses other tools under the same umbrella (e.g. scaldys-template); naming the file after the specific tool (scaldys-project) removes that ambiguity entirely and is consistent with the hyphenated package name convention. No settings, sections, or defaults are changed.

    Note

    Breaking change for consuming projects. Any project that provides a scaldys.toml file must rename it to scaldys-project.toml. The file contents remain identical; only the filename changes.

    • Documentation file scaldys_toml_reference.rst renamed to scaldys_project_toml_reference.rst and its .. _scaldys_toml_reference: label updated to .. _scaldys_project_toml_reference: accordingly.

    • All internal source code, tests, and documentation updated to reference scaldys-project.toml and scaldys_project_toml_reference.

Removed:

  • sphinx-apidoc integration removed from the documentation build pipeline.

    internal_doc_dirs (the [docs] key that triggered a sphinx-apidoc pre-pass before sphinx-build) has been removed from DocsConfig and from scaldys-project.toml. sphinx_apidoc_exe_path has been removed from BaseBuildEnvironment.

    The [docs] section now has a single key: public_doc_dirs. All documentation units are built by sphinx-build directly; API reference pages should be hand-authored using .. automodule:: directives rather than generated by sphinx-apidoc.

    Note

    Breaking change for consuming projects. Remove any internal_doc_dirs key from your scaldys-project.toml. The key is silently ignored by load_config() (unknown TOML keys are not an error), but it no longer has any effect.

Fixed:

  • Pure-Python wheel now correctly tagged py3-none-any when no compiled_modules are declared.

    Compiler._build_wheel() previously wrote a setup.py that forced a platform-specific wheel tag unconditionally. The intent was to prevent setuptools from downgrading a wheel that contains pre-built .pyd extensions to py3-none-any, but the same setup.py was injected even when compiled_modules = [] (the default), causing a pure-Python build to produce a spurious platform tag such as cp313-cp313-win_amd64. The BinaryDistribution setup.py is now only written when compiled_modules is non-empty; otherwise any stale setup.py from a previous build is removed, allowing setuptools to apply the correct py3-none-any tag.

Docs:

  • docs/manual/source/developers/markdown_formatting.rst expanded with a full technical explanation: how the pre-commit config is split between the project-level .pre-commit-config.yaml and the check-only config bundled in the wheel, the ci (check-only) vs format (fix-in-place) contract, and a scenario-by-scenario comparison of local git hook, ci markdown, format markdown, and GitHub Actions behaviour.

  • docs/manual/source/developers/contributing.rst updated to list all ci and format subcommands with their intent; cross-reference text updated to reflect the project-file / bundled-resource split.

  • docs/manual/source/users/cli_usage.rst updated with the format command group (tree, format all, format python, format markdown sections) and the corrected ci markdown description (bundled config, no project file required).

[0.11.0] - 2026-05-17

Added:

  • ci subcommand group: runs quality checks locally, mirroring the GitHub Actions pipeline step-for-step. All ci commands operate on the current working directory (not the project root), so they work for any project:

    scaldys-project ci all          # run every step; stops on first failure
scaldys-project ci lint         # uv run ruff check .
scaldys-project ci format       # uv run ruff format --diff .
scaldys-project ci typecheck    # uv sync && uv run pyright ./src

  • test command: runs the project test suite via pytest:

    scaldys-project test            # uv run pytest -v --durations=0 --cov --cov-report=xml

  • publish command: uploads the binary wheel from dist/ to PyPI via uv publish. Refuses to publish pure-Python wheels (platform tag none-any) to prevent Cython source code from being exposed on PyPI. Also refuses when multiple binary wheels are found in dist/ (stale build artifacts):

    scaldys-project publish         # upload binary wheel to PyPI
scaldys-project publish --test  # upload to TestPyPI instead

    This command is intended for consuming projects that use Cython-compiled extensions and therefore cannot rely on automated CI publishing (which would produce a pure-Python source distribution). scaldys-project itself continues to publish automatically via GitHub Actions.

Changed:

  • CLI refactored from a single monolithic __main__.py into a structured cli/ package, following the same layout as scaldys-template. The new layout:

    cli/
├── cli.py              # Typer app, logging, command wiring
├── utils.py            # shared console, find_project_root()
└── commands/
    ├── cmd_build.py    # build subcommands (unchanged behaviour)
    ├── cmd_check.py    # check command (unchanged behaviour)
    ├── cmd_ci.py       # new ci subcommands
    ├── cmd_publish.py  # new publish command
    └── cmd_test.py     # new test command

    __main__.py is now a minimal entry point that imports app from cli/cli.py. The pyproject.toml entry point is unchanged (scaldys_project.__main__:app).

    A single Console instance is now shared across logging and all build commands (via cli/utils.py) to prevent Rich live-display conflicts.

Removed:

  • ci build subcommand (uv build). The command was redundant with scaldys-project build all and actively misleading for binary-wheel projects: running uv build locally produces a pure-Python wheel, which is the wrong artifact for projects that use Cython compilation. The ci group now covers only quality gates (lint, format, typecheck), matching the scope of the GitHub Actions ci.yml workflow.

Docs:

  • Publishing guide in the developer manual updated with a Why automated publishing? section that explains the design rationale: scaldys-project is pure-Python and open-source, so CI-built wheels are the correct and complete artifact and OIDC Trusted Publishing is the most secure release mechanism. The section also contrasts with consuming projects that use Cython-compiled extensions and must publish manually via scaldys-project publish.

[0.10.0] - 2026-05-17

Docs:

  • Added Publishing guide to the developer manual covering PyPI Trusted Publishing setup, GitHub environment configuration, workflow files, version bump procedure, release triggering, and TestPyPI dry run.

[0.9.0] - 2026-05-17

Changed:

  • Configuration file renamed from builder.toml to scaldys.toml.

    The file name now matches the project name (scaldys-project) rather than describing the tool’s original role. No settings, sections, or defaults are changed.

    Note

    Breaking change for consuming projects. Any project that provides a builder.toml file must rename it to scaldys.toml. The file contents remain identical; only the filename changes.

    • Documentation file builder_toml_reference.rst renamed to scaldys_toml_reference.rst and its .. _builder_toml_reference: label updated to .. _scaldys_toml_reference: accordingly.

    • All internal source code, tests, and documentation updated to reference scaldys.toml and scaldys_toml_reference.

[0.8.0] - 2026-05-17

Changed:

  • Project renamed from scaldys-builder to scaldys-project.

    • PyPI package name changed: scaldys-builder → scaldys-project.

    • Python package (import name) changed: scaldys_builder → scaldys_project.

    • CLI entry point changed: scaldys-builder → scaldys-project.

    • Source directory renamed: src/scaldys_builder/ → src/scaldys_project/.

    All internal imports, documentation references, configuration files, and lock file entries are updated accordingly. No functional changes are introduced in this release.

    Note

    Breaking change. Any project depending on scaldys-builder must update its dependency declaration (e.g. in pyproject.toml) to scaldys-project. Any code that imports from scaldys_builder must be updated to import from scaldys_project.

[0.7.0] - 2026-05-17

Changed:

  • Build output split into two top-level directories with distinct purposes:

    • dist/ — PyPI-conventional directory for the distributable wheel. The dist/wheels/ subdirectory is eliminated; the wheel is now written directly into dist/, matching the convention expected by twine upload dist/* and uv publish.

    • artifacts/ — new top-level directory for all other build outputs that are not published to PyPI. Replaces the previous use of dist/ for non-wheel artefacts.

    Previous dist/ paths and their artifacts/ replacements:

    Old path

    New path

    dist/wheels/<name>.whl

    dist/<name>.whl

    dist/portable/

    artifacts/portable/

    dist/installer/

    artifacts/installer/

    dist/documentation/

    artifacts/documentation/

    dist/pyruntime/

    artifacts/pyruntime/

    Note

    Breaking change for consuming projects. Any Inno Setup .iss script that references dist\portable\, dist\installer\, or dist\documentation\ must be updated to reference artifacts\portable\, artifacts\installer\, and artifacts\documentation\ respectively.

  • build clean now removes artifacts/ in addition to build/ and dist/. The OneDrive slow-sync warning is updated to mention all three directories.

  • builder.toml deployment-mode documentation updated to reflect the new directory layout.

Added:

  • Pre-build compliance check for package installation in pyinstaller mode. check_compliance() now verifies that the project package is installed in the active virtual environment (i.e. a dist-info entry is present and discoverable by importlib.metadata).

    A missing dist-info previously caused copy_metadata() in the PyInstaller hook to raise a StopIteration deep inside PyInstaller, producing a cryptic traceback with no indication of the fix. The check now catches this condition before the build starts and reports:

    ✗ Package 'my-app' is not installed in the active virtual environment
  (no dist-info found). Run 'uv sync' (or 'pip install -e .') and retry.

    This most commonly occurs after renaming the project (changing name in pyproject.toml) without reinstalling.

[0.6.1] - 2026-05-15

Fixed:

  • build all in wheel_only mode now distributes built documentation to dist/documentation/ as documented in builder.toml. Previously, the entire packaging step was skipped in this mode, so Sphinx built the docs to build/<name>/html/ but they were never copied to dist/.

    A new Packager._distribute_docs() method handles this: it copies each public_doc_dirs entry from build/<name>/html/ to dist/documentation/<name>/. A Distributing documentation step now appears in the build all progress bar for wheel_only mode (previously absent).

[0.6.0] - 2026-05-14

Changed:

  • Output subdirectory dist/pyinstaller/ renamed to dist/portable/ to describe the content (copy-and-run standalone bundle) rather than the tool that produced it.

  • Output subdirectory dist/setup/ renamed to dist/installer/ to describe the artifact type (Windows installer) rather than the conventional filename of the executable it contains.

  • builder.py renamed to __main__.py, making scaldys-project consistent with the project layout it enforces on consuming projects. The module is now also runnable as python -m scaldys_project. The pyproject.toml entry point updated accordingly (scaldys_project.__main__:app).

  • Developer manual updated to reflect the rename in the module layout diagram and execution-flow description (architecture.rst) and in the new-platform-builder guide (extension_points.rst).

  • [docs] configuration keys renamed to better express their purpose: dist_dirs → public_doc_dirs (documentation units destined for end users, bundled into the installer) and apidoc_dirs → internal_doc_dirs (documentation units for project developers, not distributed to end users). Updated in config.py, docs.py, windows/builder.py, all tests, builder.toml, and the full user manual.

Docs:

  • User manual synchronised with the codebase changes introduced in 0.4.0–0.6.0. All affected pages updated in one pass

[0.5.0] - 2026-05-10

Added:

  • _build_wheel() build step: after PyInstaller completes, a .pyd-only distribution wheel is built from build/compiled/ (which contains compiled .pyd extensions only, no Python source). The step patches a copy of the project’s pyproject.toml to restrict setuptools package discovery to the project package (excluding extra_hooks/) and to declare *.pyd files as package data. The resulting wheel is placed in dist/ ready for uv pip install --find-links.

  • Online and offline installer modes: the build supports an optional PythonRuntimeDir variable in the Inno Setup .iss script. When set, the pre-built PythonRuntime directory is embedded inside setup.exe (offline mode); when absent, Python is downloaded at install time via uv (online mode).

  • .python-version compliance requirement: scaldys-project now rejects a build if the target project’s root does not contain a .python-version file. This file serves as the single source of truth for the Python version shared between the build pipeline, the wheel build, and the PythonRuntime setup script.

Changed:

  • Compliance rule set extended with the .python-version check (see scaldys-project check and the Project Compliance guide).

[0.4.0] - 2026-05-08

Added:

  • Generic documentation system: every immediate subdirectory of docs/ is now treated as an independent documentation unit. There is no longer a fixed set of names — subdirectory names are freely choosable. All units are discovered and built automatically; no configuration is needed to add a new unit.

  • Engine auto-detection: the documentation engine for each unit is determined by inspecting its contents. A source/conf.py file selects Sphinx; a mkdocs.yml selects MkDocs (detected but not yet built — a warning is logged and the unit is skipped). Units whose directory matches neither marker also produce a warning and are skipped.

  • [docs] section in builder.toml:

    • dist_dirs — list of subdirectory names whose built HTML is copied into the distribution artefacts (dist/portable/documentation/<name>/). Defaults to [] (no documentation distributed).

    • apidoc_dirs — list of subdirectory names that require a sphinx-apidoc pre-pass before sphinx-build. Defaults to []. This replaces the previously hardcoded behaviour of always running sphinx-apidoc for a directory named developer_guide.

  • DocEngine enum and _detect_engine() function in scaldys_project.common.docs, providing a testable, reusable engine detection primitive.

  • WindowsBuilder._any_sphinx_docs() helper: replaces the hardcoded check for docs/manual/ when determining whether Sphinx must be present at pre-flight time.

Changed:

  • Distribution path for documentation changed from the single fixed destination dist/portable/documentation/help files/ to dist/portable/documentation/<name>/ (one sub-folder per entry in [docs] dist_dirs).

    Note

    Breaking change for consuming projects. Any Inno Setup .iss script that references the old documentation\help files\ path must be updated to reference documentation\<name>\ instead.

  • DocumentationBuilder refactored: the two hardcoded methods build_user_guide() and build_developer_guide() are replaced by a generic build() / _build_one() / _build_sphinx() loop that works for any number of doc units.

  • BaseBuildEnvironment no longer exposes the four hardcoded path attributes user_guide_dir_path, user_guide_build_dir_path, developer_guide_dir_path, and developer_guide_build_dir_path. Paths are now derived at call-time from the directory name.

  • Documentation updated throughout: Documentation Building guide rewritten for the generic system; Configuration guide updated with the new [docs] section; Project Layout, CLI Reference, Overview, Quick Start, and Windows Installer pages updated to reflect the new paths and behaviour.

[0.4.0] - 2026-05-14

Added:

  • Three Windows deployment modes, controlled by deployment_mode in builder.toml ([windows] section):

    • "pyinstaller" (default) — existing behaviour: PyInstaller bundles the application into a self-contained executable directory; Inno Setup produces a setup.exe.

    • "pyruntime" — PyInstaller is not used. A managed Python virtual environment (PythonRuntime) is deployed alongside the application via Inno Setup. Intended for applications that must coexist with Quarto, Jupyter, or another tool that requires a real Python interpreter. setup_pyruntime.ps1, uv.exe, and .python-version are staged into dist/portable/bin/ so the installer can set up the runtime at install time.

    • "wheel_only" — builds a binary distribution wheel only; no installer is created. The Inno Setup script and launcher files are not required. Use for packages distributed via pip or uv.

  • dist/wheels/ — unified top-level output directory for the binary distribution wheel in all three modes. In pyruntime mode the wheel is additionally staged to dist/portable/wheels/ so Inno Setup can bundle it into the installer.

  • WindowsBuilder.build_distribution() — new method that runs the Windows distribution pipeline without the documentation step. Used by the new build windows CLI command.

  • WindowsBuilder._distribution_steps() — internal helper that returns the mode-dependent step list, shared by main() and build_distribution().

  • WindowsBuilder._run_steps() — internal helper that drives the Rich progress bar for a given step list; avoids duplicating the progress-bar loop between main() and build_distribution().

Changed:

  • CLI redesigned — the build windows sub-group and its five commands (exe, installer, all, docs, clean) are replaced by four flat commands directly under build:

    • build all — documentation + full Windows distribution pipeline (replaces build windows all)

    • build docs — Sphinx documentation only (replaces build windows docs)

    • build windows — Windows distribution only, no docs rebuild (replaces the separate build windows exe + build windows installer pair; behaviour is mode-dependent)

    • build clean — delete build/ and dist/ (replaces build windows clean)

  • Compliance checking is now mode-dependent. Rules 5–8 (packaging directory, .iss script, launcher scripts) are only enforced when deployment_mode is not "wheel_only". Rule 9 (.python-version) is only enforced in "pyruntime" mode.

  • Compiler.build() — PyInstaller is only invoked when deployment_mode == "pyinstaller".

  • Compiler._build_wheel() — wheel output path changed from dist/portable/bin/wheels/ to dist/wheels/ (all modes).

  • Packager.prepare_windows_files() — setup_pyruntime.ps1, .python-version, and uv.exe are staged only in pyruntime mode; wheel staging to dist/portable/wheels/ is likewise restricted to pyruntime mode.

  • Packager.run_innosetup() — passes /DPyruntimeMode=1 and optionally /DPythonRuntimeDir only in pyruntime mode.

  • Packager.build() — returns early with an informational log message in wheel_only mode (no installer step).

  • WindowsBuildEnvironment — new dist_wheels_dir_path attribute (dist/wheels/).

  • Pre-flight checks and compliance checks are skipped for irrelevant tools depending on the active mode (e.g. PyInstaller not checked in pyruntime or wheel_only mode; Inno Setup not checked in wheel_only mode).

  • User manual updated throughout: new Windows Distribution Modes guide (replaces PyInstaller Executable Bundling), updated Windows Installer Creation, CLI Reference, Configuration, Project Compliance, Project Layout, Overview, Quick Start, and builder.toml — Full Reference pages.

  • builder.toml reference updated with the new deployment_mode key and revised bundle_pyruntime documentation (now explicitly scoped to pyruntime mode).

Docs:

  • architecture.rst updated: execution flow section revised for the new CLI structure and mode-aware step list; BuildConfig dataclass diagram extended with DocsConfig, deployment_mode, and bundle_pyruntime.

[0.3.0] - 2026-05-07

Added:

  • Project compliance checking: scaldys-project now validates the target project’s required files and structure before running any build step. All issues are reported together in a single pass so they can be fixed at once. If any requirement is not met the tool exits cleanly with a descriptive message rather than failing mid-build with a cryptic error.

    Compliance is checked automatically at the start of build windows exe, build windows installer, and build windows all.

  • New top-level command scaldys-project check: runs the full compliance check on the current project without triggering a build. Useful for verifying a freshly cloned project or diagnosing issues.

  • New documentation page Project Compliance (In-Depth Guides section): lists all eight compliance rules with descriptions, the commands each rule applies to, and cross-reference links to the relevant guide sections.

Fixed:

  • Project names containing hyphens (e.g. my-app) are now normalised to underscores when resolving Python package paths (e.g. src/my_app/, my_app/__main__.py, --collect-submodules my_app), matching the Python import system convention (PEP 503 / PEP 508). The raw project name is preserved for artefact naming (executable, .iss script, launcher scripts, icon).

[0.2.0] - 2026-05-04

Added:

  • Sphinx-based user manual under docs/manual/, structured in three sections:

    Users

    • Overview — what scaldys-project does, the build pipeline diagram, and two clear entry paths (new project vs. existing project)

    • Installation — adding scaldys-project as a dev dependency with extras, external tool requirements, and installation verification

    • Quick Start — step-by-step project setup and first build walkthrough

    • CLI Reference — complete reference for every command and option

    • In-Depth Guides: project layout and build output, builder.toml configuration, documentation building, Cython compilation, Windows EXE bundling, and Inno Setup installer creation

    Developers

    • Architecture — module layout, three-class composition pattern, execution flow, configuration loading, and an explanation of why compile_runner.py runs as a subprocess

    • Extension Points — design conventions and how to add Cython modules, build steps, or a new platform builder

    • Contributing — dev environment setup, testing, linting, publishing, and testing changes against a consuming project

    About

    • Changelog, authors, license, and get-help page

  • docs/manual/Makefile and make.bat for building the HTML manual

  • licenses/ directory with license copies and credit information for all third-party tools used by scaldys-project

  • licenses/README.md index listing each tool’s license type, upstream URL, and link to the corresponding local license file

[0.1.1] - 2025-xx-xx

Changed:

  • Added uv.lock for reproducible dependency resolution

  • Minor corrections based on Pyright feedback

[0.1.0] - (unreleased)

Added:

  • Initial release extracted from scaldys-template

  • Modular build system: common base, Windows builder, Sphinx docs, Cython runner

  • builder.toml for per-project build configuration (compiled modules, packaging paths)

  • compile_runner module replaces project-level compile.py scripts