python-package-folder 3.1.3__tar.gz → 4.1.0__tar.gz

python_package_folder-4.1.0/.cursor/plans/optional_version_+_semantic-release_efed88a6.plan.md

@@ -0,0 +1,123 @@
+# Optional --version with semantic-release (both workflows)
+
+## Scope: two workflows
+
+1. **Workflow 1 – Publishing a subfolder** (monorepo): Build and publish a subfolder of `src/` as its own package. Version today is required via `--version`.
+2. **Workflow 2 – Building packages with shared code**: Build the main package (e.g. `src/my_package/`) that imports from `shared/`. Version today comes from `pyproject.toml` (dynamic or static) or `--version` when publishing.
+
+Both workflows should support **optional `--version**`: when omitted, resolve the next version via semantic-release and use it for the build/publish.
+
+## Current behavior
+
+- **CLI** ([`python_package_folder.py`](src/python_package_folder/python_package_folder.py)): For subfolder builds, `--version` is required; the tool exits with an error if it is missing (lines 158–164). For main-package builds, `--version` is optional; version comes from `pyproject.toml` or user.
+- **Manager** ([`manager.py`](src/python_package_folder/manager.py)): `prepare_build` defaults version to `"0.0.0"` with a warning when `version` is `None` for subfolders (lines 232–239). `build_and_publish` raises `ValueError` if `version` is missing for a subfolder build (lines 1254–1258). For main package, `version` can be None (no error); then publish uses whatever the build produced (dynamic versioning or static from pyproject).
+- **Publisher** ([`publisher.py`](src/python_package_folder/publisher.py)): Filters dist files by `package_name` and `version`; both are required for reliable filtering.
+
+## Target behavior
+
+- `**--version` optional for both workflows**: If `--version` is not provided and a version is needed (subfolder build, or main-package publish), compute the next version using semantic-release, then proceed with that version. If provided, keep current behavior (explicit version).
+- **Workflow 1 (subfolder)**: Per-package tags `{package-name}-v{version}` and commits filtered to the subfolder path.
+- **Workflow 2 (main package)**: Repo-level tags (e.g. `v{version}`), no path filter; run semantic-release from project root.
+
+## Architecture
+
+```mermaid
+flowchart LR
+  subgraph Workflows
+    W1[Workflow 1: Subfolder build]
+    W2[Workflow 2: Main package with shared code]
+  end
+  subgraph CLI
+    A[Build or publish without --version]
+    B[Resolve version via semantic-release]
+    C[Build and publish with resolved version]
+  end
+  W1 --> A
+  W2 --> A
+  A --> B --> C
+  B --> Node[Node: get-next-version script]
+  Node --> SR[semantic-release dry-run]
+  SR --> NextVer[Next version]
+  NextVer --> C
+```
+
+- **Version resolution**: When `--version` is missing and needed (subfolder build, or main-package publish), call a Node script that runs semantic-release in dry-run and prints the next version to stdout.
+  - **Workflow 1**: Script runs with subfolder path and package name → per-package tag format and path-filtered commits (semantic-release-commit-filter).
+  - **Workflow 2**: Script runs from project root, no path filter → default tag format `v{version}`; package name from `pyproject.toml` for Publisher filtering only.
+- **Fallback**: If Node/semantic-release is unavailable or semantic-release decides there is no release, fail with a clear message and suggest installing semantic-release (and commit-filter for subfolders) or passing `--version` explicitly.
+
+## Implementation options for “get next version”
+
+- **Option A (recommended): Small Node script using semantic-release API**  
+
+Add a script (e.g. `scripts/get-next-version.cjs` or under `.release/`) that:
+
+  - Takes args: project root, subfolder path (relative or absolute), package name.
+  - Ensures a minimal `package.json` exists in the subfolder (or in a temp location with correct `name`) so that semantic-release-commit-filter can use `package.name` for `tagFormat` and filter commits by cwd.
+  - Requires semantic-release and semantic-release-commit-filter, runs semantic-release programmatically with `dryRun: true`, and prints `nextRelease.version` (or “none”) to stdout.  
+
+This avoids parsing human-oriented dry-run output and gives a single, stable contract.
+
+- **Option B: Parse `npx semantic-release --dry-run` output**  
+
+Run the CLI in dry-run and parse stdout. Possible but brittle (format can change, localization, etc.). Not recommended.
+
+## Key implementation details
+
+1. **Where to run semantic-release**
+
+Run from the **subfolder** directory so that semantic-release-commit-filter’s “current directory” is the subfolder and commits are filtered to that path. Tag format will be `{package.name}-v${version}` from the `package.json` in that directory.
+
+2. **Temporary `package.json` in subfolder**
+
+Python subfolders usually have no `package.json`. Create a temporary one for the version resolution only: `{"name": "<package_name>"}` (same name as used for the Python package). Run semantic-release from the subfolder, then remove the temp file (or overwrite only if we created it). Document that the script may create/remove `package.json` in the subfolder so users are not surprised.
+
+3. **Dependencies**
+
+  - No new Python dependencies.  
+  - Document that **Node.js** and **npm** (or **npx**) must be available when using auto-versioning.  
+  - Document (and optionally script) install of semantic-release and semantic-release-commit-filter, e.g. `npm install -g semantic-release semantic-release-commit-filter` or per-repo `package.json` with these as devDependencies.
+
+4. **CLI flow**
+
+  - If subfolder build and `args.version` is None:  
+    - Call the version resolver (subprocess: `node scripts/get-next-version.cjs <project_root> <subfolder_path> <package_name>`).  
+    - If resolver returns a version string: use it for the rest of the flow.  
+    - If resolver returns “none” or fails (no release / semantic-release not found / Node error): exit with a clear error suggesting to pass `--version` or to install and configure semantic-release.
+  - Pass the resolved or explicit version into `build_and_publish` / `prepare_build` as today.
+
+5. **Manager / Publisher**
+
+No change to the contract: they still receive a concrete `version` (either from CLI or from the resolver). Only the CLI and the new resolution step change.
+
+6. **Convention**
+
+Rely on default Angular/conventional commit rules (e.g. `fix:` → patch, `feat:` → minor, `BREAKING CHANGE:` → major). Document that conventional commits are required for auto-versioning; no change to commit format inside this repo unless you add a config file for semantic-release.
+
+## Files to add or touch
+
+| Item       | Action                                                                                                                                                                                                                                                                                                          |
+
+| ---------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+
+| New script | Add `scripts/get-next-version.cjs` (or similar) that runs semantic-release in dry-run with commit-filter and prints next version.                                                                                                                                                                               |
+
+| CLI        | In [`python_package_folder.py`](src/python_package_folder/python_package_folder.py): when `is_subfolder and not args.version`, call the resolver; on success set `args.version` (or a local variable) to the resolved version; on failure exit with error. Remove the “version required” error for this case.   |
+
+| Manager    | In [`manager.py`](src/python_package_folder/manager.py): keep the `ValueError` when `version` is None for subfolder in `build_and_publish` (CLI will always pass a version after resolution). Optionally keep or adjust the “default 0.0.0” in `prepare_build` for programmatic callers who still omit version. |
+
+| Docs       | Update README (and any publishing doc) to describe: `--version` optional for subfolders when semantic-release is used, per-package tags, conventional commits, and Node/npm + semantic-release (and commit-filter) setup.                                                                                       |
+
+| Tests      | Add tests for: CLI with subfolder and no `--version` (mock or skip if Node/semantic-release missing), and for the resolver helper (or script) when given a fixture repo with tags and conventional commits.                                                                                                     |
+
+## Open decisions
+
+- **Script location**: Ship `get-next-version.cjs` inside this repo under `scripts/` (or `.release/`) so that `python-package-folder` can invoke it without requiring the user to add it. The script will `require('semantic-release')` and `require('semantic-release-commit-filter')`; users must have these installed (globally or in a local `package.json` at project root or subfolder).
+- **First release / no tag**: If there is no tag for this package yet, semantic-release will use an initial version (e.g. 1.0.0). Confirm desired behavior (e.g. configurable first version or always 1.0.0).
+- **No release (no relevant commits)**: If semantic-release determines there is no release, the script should output something like “none” and the CLI should exit with a clear message rather than defaulting to 0.0.0.
+
+## Summary
+
+- Make `--version` optional for subfolder builds by resolving the next version via Node.js semantic-release with per-package tags and path-filtered commits.
+- Add a small Node script that runs semantic-release in dry-run and prints the next version; wire it from the CLI when `--version` is omitted.
+- Document Node/npm and semantic-release (and semantic-release-commit-filter) as requirements for this mode, and keep explicit `--version` as the fallback when auto-versioning is not available or not desired.

{python_package_folder-3.1.3 → python_package_folder-4.1.0}/.github/workflows/ci.yml

@@ -59,6 +59,10 @@ jobs:
       - name: Run linting
         run: uv run ruff check .
 
+      - name: Check formatting
+        continue-on-error: true
+        run: uv run ruff format --check .
+
       - name: Run type checking
         run: uv run basedpyright src/ || true
 

{python_package_folder-3.1.3 → python_package_folder-4.1.0}/.github/workflows/publish.yml

@@ -4,6 +4,11 @@ on:
   release:
     types: [published]
   workflow_dispatch: # Enable manual trigger.
+    inputs:
+      version:
+        description: 'Package version to publish (e.g., 4.0.1). Required for manual triggers.'
+        required: true
+        type: string
 
 jobs:
   build-and-publish:
@@ -58,6 +63,40 @@ jobs:
           rm -rf dist/
           echo "✓ Cleaned dist/ directory"
 
+      - name: Extract version from release tag or input
+        id: version
+        run: |
+          if [ "${{ github.event_name }}" = "release" ]; then
+            # Extract from release tag
+            VERSION="${{ github.event.release.tag_name }}"
+            # Strip 'v' prefix if present
+            VERSION="${VERSION#v}"
+            echo "version=$VERSION" >> $GITHUB_OUTPUT
+            echo "Extracted version from release tag: $VERSION"
+          else
+            # For workflow_dispatch, use the provided input
+            VERSION="${{ github.event.inputs.version }}"
+            if [ -z "$VERSION" ]; then
+              echo "Error: Version is required for manual workflow_dispatch triggers"
+              exit 1
+            fi
+            # Strip 'v' prefix if present (user might include it)
+            VERSION="${VERSION#v}"
+            echo "version=$VERSION" >> $GITHUB_OUTPUT
+            echo "Using version from workflow input: $VERSION"
+          fi
+
+      - name: Set version for release
+        if: steps.version.outputs.version != ''
+        run: |
+          python -c "
+          from pathlib import Path
+          from python_package_folder.version import VersionManager
+          version_manager = VersionManager(project_root=Path('.'))
+          version_manager.set_version('${{ steps.version.outputs.version }}')
+          print(f'✓ Set version to ${{ steps.version.outputs.version }}')
+          "
+
       - name: Build package
         run: uv build
 

{python_package_folder-3.1.3 → python_package_folder-4.1.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: python-package-folder
-Version: 3.1.3
+Version: 4.1.0
 Summary: Python package to automatically package and build a folder, fetching all relevant dependencies.
 Project-URL: Repository, https://github.com/alelom/python-package-folder
 Author-email: Alessio Lombardi <work@alelom.com>
@@ -75,6 +75,9 @@ cd src/api_package
 # Build and publish to TestPyPI with version 1.2.0
 python-package-folder --publish testpypi --version 1.2.0
 
+# Or publish to PyPI with automatic version resolution via semantic-release
+python-package-folder --publish pypi
+
 # Or publish to PyPI with a custom package name
 python-package-folder --publish pypi --version 1.2.0 --package-name "my-api-package"
 
@@ -169,6 +172,13 @@ uv add twine
 
 **For secure credential storage**: `keyring` is optional but recommended (install with `pip install keyring`)
 
+**For automatic version resolution**: When using `--version` optional mode (automatic version resolution via semantic-release), you'll need:
+- Node.js and npm (or npx)
+- semantic-release: `npm install -g semantic-release`
+- For subfolder builds: semantic-release-commit-filter: `npm install -g semantic-release-commit-filter`
+
+Alternatively, install these as devDependencies in your project's `package.json`.
+
 
 ## Quick Start
 
@@ -182,9 +192,13 @@ Useful for monorepos containing many subfolders that may need publishing as stan
 # First cd to the specific subfolder
 cd src/subfolder_to_build_and_publish
 
-# Build and publish any subdirectory of your repo to TestPyPi (https://test.pypi.org/) 
+# Build and publish any subdirectory of your repo to TestPyPi (https://test.pypi.org/)
+# Version can be provided explicitly or resolved automatically via semantic-release
 python-package-folder --publish testpypi --version 0.0.2
 
+# Or let semantic-release determine the next version automatically (requires semantic-release setup)
+python-package-folder --publish testpypi
+
 # Only analyse (no building)
 cd src/subfolder_to_build_and_publish
 python-package-folder --analyze-only
@@ -457,33 +471,89 @@ The `--version` option:
 **Version Format**: Versions must follow PEP 440 (e.g., `1.2.3`, `1.2.3a1`, `1.2.3.post1`, `1.2.3.dev1`)
 
 
+### Automatic Version Resolution (semantic-release)
+
+When `--version` is not provided, the tool can automatically determine the next version using semantic-release. This requires Node.js, npm, and semantic-release to be installed.
+
+**Version Detection:**
+- **Baseline version**:
+  - **Registry Query (Preferred)**: When publishing to a repository (PyPI, TestPyPI, or Azure Artifacts), the tool queries the target registry for the latest published version and uses it as the baseline for version calculation. This ensures version calculations are based on what's actually published, not just git tags.
+  - **Git Tags (Fallback)**: If the package doesn't exist on the registry yet (first release) or if registry query fails, the tool falls back to using git tags to determine the starting version.
+- **New version to publish**: After determining the baseline version, [`semantic-release`](https://semantic-release.gitbook.io/semantic-release/) analyzes commits since that version to calculate the next version bump (major, minor, or patch) based on [_conventional commit_](https://www.conventionalcommits.org/en/v1.0.0/) messages.
+
+**For subfolder builds (Workflow 1):**
+- Uses per-package tags: `{package-name}-v{version}` (e.g., `my-package-v1.2.3`)
+- Queries the target registry for the latest published version of the subfolder package
+- Filters commits to only those affecting the subfolder path
+- **Commit filtering behavior**: Only commits that modify files within the subfolder path are considered for version calculation. Commits that only target files outside the subfolder are excluded. For example:
+  - `fix: update my_subfolder/foo.py` → **Included** (affects subfolder)
+  - `feat: add feature to other_package/bar.py` → **Excluded** (doesn't affect subfolder)
+  - `fix: update my_subfolder/baz.py and shared/utils.py` → **Included** (affects subfolder, even if it also touches files outside)
+- Requires `semantic-release-commit-filter` plugin
+
+**For main package builds (Workflow 2):**
+- Uses repo-level tags: `v{version}` (e.g., `v1.2.3`)
+- Queries the target registry for the latest published version when publishing
+- Analyzes all commits in the repository
+
+**Registry Support:**
+- **PyPI**: Fully supported via JSON API (`https://pypi.org/pypi/{package-name}/json`)
+- **TestPyPI**: Fully supported via JSON API (`https://test.pypi.org/pypi/{package-name}/json`)
+- **Azure Artifacts**: Basic support with fallback to git tags. Azure Artifacts uses a different API format and may require authentication, so if the query fails, the tool automatically falls back to git tags.
+
+**Setup:**
+```bash
+# Install semantic-release globally
+npm install -g semantic-release
+
+# For subfolder builds, also install semantic-release-commit-filter
+npm install -g semantic-release-commit-filter
+```
+
+**Usage:**
+```bash
+# Subfolder build - version resolved automatically
+cd src/my_subfolder
+python-package-folder --publish pypi
+
+# Main package - version resolved automatically
+python-package-folder --publish pypi
+```
+
+**Requirements:**
+- Conventional commits (e.g., `fix:`, `feat:`, `BREAKING CHANGE:`) are required for semantic-release to determine version bumps
+- The tool will fall back to requiring `--version` explicitly if semantic-release is not available or determines no release is needed
+
 ### Subfolder Versioning
 
 When building from a subdirectory (not the main `src/` directory), the tool automatically detects the subfolder and sets up the build configuration:
 
 ```bash
-# Build a subfolder as a separate package (version recommended but not required)
+# Build a subfolder as a separate package with explicit version
 cd my_project/subfolder_to_build
 python-package-folder --version "1.0.0" --publish pypi
 
+# Or let semantic-release determine the version automatically
+python-package-folder --publish pypi
+
 # With custom package name
 python-package-folder --version "1.0.0" --package-name "my-custom-name" --publish pypi
-
-# Version defaults to "0.0.0" if not specified (with a warning)
-python-package-folder --publish pypi
 ```
 
 For subfolder builds:
 - **Automatic detection**: The tool automatically detects subfolder builds
+- **Version resolution**: 
+  - If `--version` is provided: Uses the explicit version
+  - If `--version` is omitted: Attempts to resolve via semantic-release (requires setup)
+  - If semantic-release is unavailable or determines no release: Requires `--version` explicitly
 - **pyproject.toml handling**:
   - If `pyproject.toml` exists in subfolder: Uses that file (copied to project root temporarily)
   - If no `pyproject.toml` in subfolder: Creates temporary one with correct package structure
-- **Version**: Recommended but not required when creating temporary pyproject.toml. If not provided, defaults to `0.0.0` with a warning. Ignored if subfolder has its own `pyproject.toml`.
 - **Package name**: Automatically derived from the subfolder name (e.g., `subfolder_to_build` → `subfolder-to-build`). Only used when creating temporary pyproject.toml.
 - **Restoration**: Original `pyproject.toml` is restored after build
 - **Temporary configuration**: Creates a temporary `pyproject.toml` with:
   - Custom package name (from `--package-name` or derived)
-  - Specified version
+  - Specified or resolved version
   - Correct package path for hatchling
   - Dependency group from parent (if `--dependency-group` is specified)
 - **Package initialization**: Automatically creates `__init__.py` if the subfolder doesn't have one (required for hatchling)
@@ -686,7 +756,8 @@ options:
   --password PASSWORD   Password/token for publishing (will prompt if not provided)
   --skip-existing       Skip files that already exist on the repository
   --version VERSION     Set a specific version before building (PEP 440 format).
-                        Required for subfolder builds.
+                        Optional: if omitted, version will be resolved via
+                        semantic-release (requires Node.js and semantic-release setup).
   --package-name PACKAGE_NAME
                         Package name for subfolder builds (default: derived from
                         source directory name)

{python_package_folder-3.1.3 → python_package_folder-4.1.0}/README.md

@@ -55,6 +55,9 @@ cd src/api_package
 # Build and publish to TestPyPI with version 1.2.0
 python-package-folder --publish testpypi --version 1.2.0
 
+# Or publish to PyPI with automatic version resolution via semantic-release
+python-package-folder --publish pypi
+
 # Or publish to PyPI with a custom package name
 python-package-folder --publish pypi --version 1.2.0 --package-name "my-api-package"
 
@@ -149,6 +152,13 @@ uv add twine
 
 **For secure credential storage**: `keyring` is optional but recommended (install with `pip install keyring`)
 
+**For automatic version resolution**: When using `--version` optional mode (automatic version resolution via semantic-release), you'll need:
+- Node.js and npm (or npx)
+- semantic-release: `npm install -g semantic-release`
+- For subfolder builds: semantic-release-commit-filter: `npm install -g semantic-release-commit-filter`
+
+Alternatively, install these as devDependencies in your project's `package.json`.
+
 
 ## Quick Start
 
@@ -162,9 +172,13 @@ Useful for monorepos containing many subfolders that may need publishing as stan
 # First cd to the specific subfolder
 cd src/subfolder_to_build_and_publish
 
-# Build and publish any subdirectory of your repo to TestPyPi (https://test.pypi.org/) 
+# Build and publish any subdirectory of your repo to TestPyPi (https://test.pypi.org/)
+# Version can be provided explicitly or resolved automatically via semantic-release
 python-package-folder --publish testpypi --version 0.0.2
 
+# Or let semantic-release determine the next version automatically (requires semantic-release setup)
+python-package-folder --publish testpypi
+
 # Only analyse (no building)
 cd src/subfolder_to_build_and_publish
 python-package-folder --analyze-only
@@ -437,33 +451,89 @@ The `--version` option:
 **Version Format**: Versions must follow PEP 440 (e.g., `1.2.3`, `1.2.3a1`, `1.2.3.post1`, `1.2.3.dev1`)
 
 
+### Automatic Version Resolution (semantic-release)
+
+When `--version` is not provided, the tool can automatically determine the next version using semantic-release. This requires Node.js, npm, and semantic-release to be installed.
+
+**Version Detection:**
+- **Baseline version**:
+  - **Registry Query (Preferred)**: When publishing to a repository (PyPI, TestPyPI, or Azure Artifacts), the tool queries the target registry for the latest published version and uses it as the baseline for version calculation. This ensures version calculations are based on what's actually published, not just git tags.
+  - **Git Tags (Fallback)**: If the package doesn't exist on the registry yet (first release) or if registry query fails, the tool falls back to using git tags to determine the starting version.
+- **New version to publish**: After determining the baseline version, [`semantic-release`](https://semantic-release.gitbook.io/semantic-release/) analyzes commits since that version to calculate the next version bump (major, minor, or patch) based on [_conventional commit_](https://www.conventionalcommits.org/en/v1.0.0/) messages.
+
+**For subfolder builds (Workflow 1):**
+- Uses per-package tags: `{package-name}-v{version}` (e.g., `my-package-v1.2.3`)
+- Queries the target registry for the latest published version of the subfolder package
+- Filters commits to only those affecting the subfolder path
+- **Commit filtering behavior**: Only commits that modify files within the subfolder path are considered for version calculation. Commits that only target files outside the subfolder are excluded. For example:
+  - `fix: update my_subfolder/foo.py` → **Included** (affects subfolder)
+  - `feat: add feature to other_package/bar.py` → **Excluded** (doesn't affect subfolder)
+  - `fix: update my_subfolder/baz.py and shared/utils.py` → **Included** (affects subfolder, even if it also touches files outside)
+- Requires `semantic-release-commit-filter` plugin
+
+**For main package builds (Workflow 2):**
+- Uses repo-level tags: `v{version}` (e.g., `v1.2.3`)
+- Queries the target registry for the latest published version when publishing
+- Analyzes all commits in the repository
+
+**Registry Support:**
+- **PyPI**: Fully supported via JSON API (`https://pypi.org/pypi/{package-name}/json`)
+- **TestPyPI**: Fully supported via JSON API (`https://test.pypi.org/pypi/{package-name}/json`)
+- **Azure Artifacts**: Basic support with fallback to git tags. Azure Artifacts uses a different API format and may require authentication, so if the query fails, the tool automatically falls back to git tags.
+
+**Setup:**
+```bash
+# Install semantic-release globally
+npm install -g semantic-release
+
+# For subfolder builds, also install semantic-release-commit-filter
+npm install -g semantic-release-commit-filter
+```
+
+**Usage:**
+```bash
+# Subfolder build - version resolved automatically
+cd src/my_subfolder
+python-package-folder --publish pypi
+
+# Main package - version resolved automatically
+python-package-folder --publish pypi
+```
+
+**Requirements:**
+- Conventional commits (e.g., `fix:`, `feat:`, `BREAKING CHANGE:`) are required for semantic-release to determine version bumps
+- The tool will fall back to requiring `--version` explicitly if semantic-release is not available or determines no release is needed
+
 ### Subfolder Versioning
 
 When building from a subdirectory (not the main `src/` directory), the tool automatically detects the subfolder and sets up the build configuration:
 
 ```bash
-# Build a subfolder as a separate package (version recommended but not required)
+# Build a subfolder as a separate package with explicit version
 cd my_project/subfolder_to_build
 python-package-folder --version "1.0.0" --publish pypi
 
+# Or let semantic-release determine the version automatically
+python-package-folder --publish pypi
+
 # With custom package name
 python-package-folder --version "1.0.0" --package-name "my-custom-name" --publish pypi
-
-# Version defaults to "0.0.0" if not specified (with a warning)
-python-package-folder --publish pypi
 ```
 
 For subfolder builds:
 - **Automatic detection**: The tool automatically detects subfolder builds
+- **Version resolution**: 
+  - If `--version` is provided: Uses the explicit version
+  - If `--version` is omitted: Attempts to resolve via semantic-release (requires setup)
+  - If semantic-release is unavailable or determines no release: Requires `--version` explicitly
 - **pyproject.toml handling**:
   - If `pyproject.toml` exists in subfolder: Uses that file (copied to project root temporarily)
   - If no `pyproject.toml` in subfolder: Creates temporary one with correct package structure
-- **Version**: Recommended but not required when creating temporary pyproject.toml. If not provided, defaults to `0.0.0` with a warning. Ignored if subfolder has its own `pyproject.toml`.
 - **Package name**: Automatically derived from the subfolder name (e.g., `subfolder_to_build` → `subfolder-to-build`). Only used when creating temporary pyproject.toml.
 - **Restoration**: Original `pyproject.toml` is restored after build
 - **Temporary configuration**: Creates a temporary `pyproject.toml` with:
   - Custom package name (from `--package-name` or derived)
-  - Specified version
+  - Specified or resolved version
   - Correct package path for hatchling
   - Dependency group from parent (if `--dependency-group` is specified)
 - **Package initialization**: Automatically creates `__init__.py` if the subfolder doesn't have one (required for hatchling)
@@ -666,7 +736,8 @@ options:
   --password PASSWORD   Password/token for publishing (will prompt if not provided)
   --skip-existing       Skip files that already exist on the repository
   --version VERSION     Set a specific version before building (PEP 440 format).
-                        Required for subfolder builds.
+                        Optional: if omitted, version will be resolved via
+                        semantic-release (requires Node.js and semantic-release setup).
   --package-name PACKAGE_NAME
                         Package name for subfolder builds (default: derived from
                         source directory name)

{python_package_folder-3.1.3 → python_package_folder-4.1.0}/coverage.svg

@@ -14,7 +14,7 @@
   <g fill="#fff" text-anchor="middle" font-family="DejaVu Sans,Verdana,Geneva,sans-serif" font-size="11">
     <text x="31.5" y="15" fill="#010101" fill-opacity=".3">coverage</text>
     <text x="31.5" y="14">coverage</text>
-    <text x="81" y="15" fill="#010101" fill-opacity=".3">69%</text>
-    <text x="81" y="14">69%</text>
+    <text x="81" y="15" fill="#010101" fill-opacity=".3">65%</text>
+    <text x="81" y="14">65%</text>
   </g>
 </svg>

{python_package_folder-3.1.3 → python_package_folder-4.1.0}/pyproject.toml

@@ -14,7 +14,6 @@ authors = [
 readme = "README.md"
 license = "MIT"
 requires-python = ">=3.11,<4.0"
-dynamic = ["version"]
 
 # https://pypi.org/classifiers/
 # Adjust as needed:
@@ -43,6 +42,7 @@ dependencies = [
 
 # ---- Dev dependencies ----
 
+version = "4.1.0"
 [dependency-groups]
 dev = [
     "pytest>=8.3.5",
@@ -71,20 +71,8 @@ python-package-folder = "python_package_folder.python_package_folder:main"
 requires = ["hatchling", "uv-dynamic-versioning"]
 build-backend = "hatchling.build"
 
-[tool.hatch.version]
-source = "uv-dynamic-versioning"
-# Note JSON schemas don't seem to be right for tool.hatch.version.source so
-# this may cause false warnings in IDEs.
-# https://github.com/ninoseki/uv-dynamic-versioning/issues/21
-
-[tool.uv-dynamic-versioning]
-vcs = "git"
-style = "pep440"
-bump = true
-
-[tool.hatch.build.targets.wheel]
-# The source location for the package.
-packages = ["src/python_package_folder"]
+[tool.hatch.build.hooks.custom]
+path = "src/python_package_folder/_hatch_build.py"
 
 
 # ---- Settings ----
@@ -164,12 +152,14 @@ reportUnreachable = false
 # skip = "foo.py,bar.py"
 
 [tool.pytest.ini_options]
-python_files = ["*.py"]
+python_files = ["test_*.py", "*_test.py"]
 python_classes = ["Test*"]
 python_functions = ["test_*"]
 testpaths = [
     "src",
     "tests",
 ]
+# Ignore build hooks - they're not test files and require hatchling which isn't in test deps
+ignore = ["_hatch_build.py"]
 norecursedirs = []
 filterwarnings = []