v0.51.0

@pipelex/sdk on npm

Added

• A method copied into another organization: copyMethod(methodId, { destination_org_id, name, expected_draft_updated_at }, { idempotencyKey }) sends POST /v1/methods/{method_id}/copy, which makes a new, unpublished method in an organization the caller may change methods in, the method's own for a duplicate, holding the original's draft tree, its form inputs and its saved examples, with the stored files they name copied into the destination, and leaves the original as it was. It answers a MethodCopyResult discriminated on outcome: copied, a MethodCopied with the copy as method, examples_copied and stored_files_copied, or refused, a MethodCopyRefused naming every BundleStorageReference of a .mthds file that names storage the destination cannot read, nothing written. Only a web session may copy. The idempotencyKey, held to a start's rule, is sent as the Idempotency-Key header, so a copy whose answer was lost can be sent again and makes one copy; the new MethodCopyRequestOptions type carries it (docs/method-copy.md).
• The copies of a method: listMethodCopies(methodId, { limit, cursor }) reads GET /v1/methods/{method_id}/copies, a MethodCopyPage of the MethodCopyMarker rows the original keeps, each naming the copy, its destination by id alone, the member who made it and when, its next_cursor read as nextCursor.
• copied_from on a method: MethodData, and so every method read, gains copied_from, a MethodCopiedFrom naming the original organization, method and draft digest on a copy, null on a method created afresh and absent from a platform that predates copies.
• The copy's codes: MethodErrorCode gains organization_not_found, a destination the caller does not belong to or that does not exist, answered alike, and method_copy_too_large, a copy past its bounds on the stored files it copies, whose problemDocument.limit the new MethodCopyLimit type reads. MethodCopyInput, MethodCopyOutcome, MethodCopyRefusalReason and ListMethodCopiesQuery are exported with them.

pipelex-sdk on PyPI

Added

• A method copied into another organization: copy_method(method_id, destination_org_id=, name=, expected_draft_updated_at=, idempotency_key=) sends POST /v1/methods/{method_id}/copy, which makes a new, unpublished method in an organization the caller may change methods in, the method's own for a duplicate, holding the original's draft tree, its form inputs and its saved examples, with the stored files they name copied into the destination, and leaves the original as it was. It answers a MethodCopyResult, read by MethodCopyResultAdapter and discriminated on outcome: MethodCopied with the copy as method, examples_copied and stored_files_copied, or MethodCopyRefused naming every BundleStorageReference of a .mthds file that names storage the destination cannot read, nothing written. Only a web session may copy. The idempotency_key, held to a start's rule, is sent as the Idempotency-Key header, so a copy whose answer was lost can be sent again and makes one copy (docs/method-copy.md).
• The copies of a method: list_method_copies(method_id, limit=, cursor=) reads GET /v1/methods/{method_id}/copies, a MethodCopyPage of the MethodCopyMarker rows the original keeps, each naming the copy, its destination by id alone, the member who made it and when.
• copied_from on a method: MethodData, and so every method read, gains copied_from, a MethodCopiedFrom naming the original organization, method and draft digest on a copy, and None on a method created afresh or from a platform that predates copies.
• The copy's codes: MethodErrorCode gains ORGANIZATION_NOT_FOUND, a destination the caller does not belong to or that does not exist, answered alike, and METHOD_COPY_TOO_LARGE, a copy past its bounds on the stored files it copies, whose problem document's limit the new MethodCopyLimit reads. MethodCopyOutcome and MethodCopyRefusalReason name the verdict's wire values.

Fixed

• A request body holding a lone surrogate: a product request whose body holds a surrogate standing alone, such as a rename_method, create_method_example or copy_method name ending in \ud800, is sent with the surrogate escaped, as @pipelex/sdk sends it, and the platform's 422 validation_failed is raised as an ApiResponseError, rather than a raw PydanticSerializationError raised before any request.

@pipelex/create-method-app on npm, with the method-app templates

Added

• PYTHON_VERSION=<version> make install in the CLI template: its Makefile takes the version from PYTHON_VERSION, then UV_PYTHON, then .python-version, and exports it as UV_PYTHON, so every uv command it runs builds .venv on that version, as UV_PYTHON=<version> make install alone did before. Each job of its lint and tests matrices ends by checking that .venv runs the version the job names.

Changed

• A dropped file the organization already holds is not uploaded again: the web app template runs on @pipelex/sdk 0.50.0, and useFileInputs describes each dropped file with the SDK's describeUpload, which computes its SHA-256 in the browser, and sends the digest with the upload grant request, so a file already stored, dropped again or kept from an earlier run, is answered as stored and the form takes its reference without sending the bytes, while a page served over plain http from a host other than the local one, where the browser offers no Web Crypto, uploads as before. The grant action make add-method writes refuses a digest that is not 64 lowercase hexadecimal digits, a file that cannot be read to hash is shown beside the field as one that could not be prepared, and the grant request now needs a platform that serves hashed uploads, since one that predates them refuses the digest; nothing else in the SDK's release reaches the app, and the CLI stays on pipelex-sdk 0.48.1.

The JavaScript starter, Pipelex/pipelex-starter-js

Changed

• A dropped file the organization already holds is not uploaded again: the starter runs on @pipelex/sdk 0.50.0, and useFileInputs describes each dropped file, the sample PDF included, with the SDK's describeUpload, which computes its SHA-256 in the browser, and sends the digest with the upload grant request, so a file already stored is answered as stored and the form takes its reference without sending the bytes, while a page served over plain http from a host other than the local one, where the browser offers no Web Crypto, uploads as before. The PDF example's grant action, and every one make add-method writes, refuses a digest that is not 64 lowercase hexadecimal digits, a file that cannot be read to hash is shown beside the field as one that could not be prepared, and the grant request now needs a platform that serves hashed uploads, since one that predates them refuses the digest; nothing else in the SDK's releases since 0.48.1 reaches the starter.

The Python starter, Pipelex/pipelex-starter-python

Added

• .python-version pins the project's Python to 3.13: uv reads the file, as pyenv, mise and actions/setup-python do, so make install, uv sync and uv run build .venv on 3.13 rather than on the newest Python on the machine, and the next make install moves an environment built on another Python back to it. Each job of the lint and tests matrices in .github/workflows/ sets UV_PYTHON to its version for the whole job and ends by checking that .venv runs that version.

Fixed

• PYTHON_VERSION=<version> make install moves an existing environment to that version: the Makefile takes the version from PYTHON_VERSION, then UV_PYTHON, then .python-version, and exports it as UV_PYTHON, so the uv sync it runs builds .venv on that version, where an existing .venv used to keep the Python it was created with.