v0.47.0

@pipelex/sdk on npm

Added

• A saved method's tree, saved by hash: createMethod and writeDraft take the method's tree as files, the MTHDS standard's map of file entries sent as given, as tree, any MethodTreeSource such as the MethodTree the mthds package's listMethodTree lists from a directory, or as contents, each file's bytes or text by tree path; the last two travel inline when their map weighs INLINE_TREE_MAX_BYTES or less, and otherwise by hash, after POST /v1/blobs/missing names the files the organization lacks and the client uploads those once, each checked against the tree's listing first, so a large method saves in a small request (docs/method-trees.md). A tree holding no file is refused before any request, and an answer asking for a blob the tree does not hold is an ApiResponseError of an answer the SDK cannot read.
• A saved method's tree, read and written to disk: getMethod answers a MethodDetail and getMethodVersion a MethodVersion whose files list the tree, each SavedMethodFile with its path, sha256, size and a link to its bytes valid for about fifteen minutes, and writeMethodTree(files, { destination }), in Node, downloads them with no credential of the client, checks each against its size and SHA-256, and writes the tree into a fresh directory that takes its name only once complete. An answer of these routes the SDK cannot read, a sha256 that is not 64 lower-case hex digits among them, reaches its ApiResponseError with every link redacted in responseBody and no cause, a link being a bearer credential.
• methodTreeLimits: the limits the deployment announces for a method's tree in its version handshake, in the shape listMethodTree takes as its limits option, so a tree the platform would refuse is refused while it is listed. The client asks for the handshake once and keeps its answer for methodTreeLimits and every save by hash.
• requestTimeoutMs: a PipelexApiClient option setting the client's request ceiling, twenty minutes by default as before: the time limit of a request given no timeoutMs of its own, the blocking execute and a save carrying a method's tree among them, since a tree sent inline to a platform with no blob store has no size bound, and of each upload before a save and each download by writeMethodTree, which it bounds whole, the body included.
• MethodFileTransferError: thrown when a file of a method's tree could not be uploaded before a save or downloaded by writeMethodTree, with its operation, a code (unreachable, storage_error, refused or mismatch) deciding whether it is retryable, the file's sha256 and path, and storage's status, and never the link, which is a bearer credential, nor a cause.
• RunDetail.tree_digest and RunDetail.crate_fingerprint: the digest of the method tree a run sent and the crate the runner loaded it into, each null for a run that recorded none.

Changed

• A saved method is a tree, and its source fields are gone (Breaking): MethodData, MethodVersion, MethodWriteInput and MethodDraftInput lose mthds and python, and MethodVersionSummary.source_digest is now tree_digest, so code reading a method's source reads its files instead, and a draft is unchanged since its latest version when draft_digest is not null and equals latest_published.tree_digest. draft_digest is the draft's tree digest, sha256: and 64 hex digits, and null for an empty draft. A stored method or version whose files is not a listing is an ApiResponseError, and getMethodVersion answers a version stored before methods were trees with a 409 whose verdict is runtime.
• writeDraft replaces the whole tree (Breaking): a draft write always sends files and refuses a MethodDraftInput that gives the tree in no form, so keeping the stored files means sending them again; files: null empties the draft.

Removed

• The catalog-source readers (Breaking): methodSourceToContents, getMethodClosure and EmptyMethodSourceError are gone with the fields they read; a method's files come back as MethodDetail.files, and writeMethodTree puts them on disk.

pipelex-sdk on PyPI

Added

• A saved method's tree, saved by hash: create_method and write_draft take the method's tree as files, the MTHDS standard's map of file entries sent as given, as tree, a tree listed from a directory by the new list_method_tree, or as contents, each file's bytes or text by tree path; the last two travel inline when small and otherwise by hash, after POST /v1/blobs/missing names the files the organization lacks and the client uploads those once, so a large method saves in a small request (docs/method-trees.md). An answer of that route this SDK cannot read, or one asking for a blob the tree does not hold, is an ApiResponseError of an answer the SDK cannot read, as are the same answers to prepare_files.
• A saved method's tree, read and written to disk: get_method answers a MethodDetail and get_method_version a MethodVersion whose files list the tree, each SavedMethodFile with its path, sha256, size and a link to its bytes valid for about fifteen minutes, and write_method_tree(files, destination=…) downloads them, each under request_timeout_seconds for its whole exchange, checks each against its size and SHA-256, stops at the first failure, and writes the tree into a fresh directory that takes its name only once complete, leaving nothing behind when it fails or is cancelled; a relative destination, Path(".") included, names the directory it means. An answer of these routes the SDK cannot read, a sha256 that is not 64 lower-case hex digits among them, reaches its ApiResponseError with every link redacted in response_body, and chains at most a copy of pydantic's refusal with its links redacted, a link being a bearer credential that a SavedMethodFile's repr leaves out too.
• method_tree_limits: the limits the deployment announces for a method's tree in its version handshake, as mthds's TreeLimits, which list_method_tree applies so a tree the platform would refuse is refused while it is listed.
• MethodFileTransferError: raised when a file of a method's tree could not be uploaded before a save or downloaded by write_method_tree, with its operation, a code (unreachable, storage_error, refused or mismatch) deciding whether it is retryable, the file's sha256 and path, storage's status, and as problem the reading of that status, never a problem document storage answered with, which can quote the signed request, or the standard's reading of an upload that got no answer, and never the link, which is a bearer credential, nor a cause or a context holding it: httpx's error, a body it could not decode included, becomes this error.
• files on the run routes: execute, start and start_and_wait take files, the standard's map of file entries, beside mthds_contents, now a keyword-only argument this client sends as the Pipelex API's extension, and only when it holds a bundle, so an empty list never reaches the wire beside another source; method_ref beside files is refused before sending, as beside mthds_contents.
• RunDetail.tree_digest and RunDetail.crate_fingerprint: the digest of the method tree a run sent and the crate the runner loaded it into, each None for a run that recorded none.

Changed

• A saved method is a tree, and its source fields are gone (Breaking): MethodData loses mthds and python, MethodWriteInput and MethodDraftInput refuse them, and MethodVersionSummary.source_digest is now tree_digest, so code reading a method's source reads its files instead, and a draft is unchanged since its latest version when draft_digest is not None and equals latest_published.tree_digest. draft_digest is the draft's tree digest, sha256: and 64 hex digits, and None for an empty draft.
• start_and_wait takes every argument but pipe_code by name (Breaking): files, mthds_contents, inputs, wait_options and the rest are keyword-only, so a call that passed mthds_contents or a later argument positionally names it instead, and no positional call reads one run source as another; execute and start keep the protocol client's positional order, with files second.
• write_draft replaces the whole tree (Breaking): a draft write always sends files and refuses a MethodDraftInput that gives the tree in no form, so keeping the stored files means sending them again; files=None empties the draft.
• Requires mthds 0.25.0 (Breaking): the exact pin moves from mthds==0.22.1 to mthds==0.25.0, the release that carries both the problem document 0.22.1 brought and the method-tree library and the blob routes the saves are built on, and whose client takes a run's method as files; mthds_contents given positionally to execute or start must now be given by name, and a run's inputs.json or inputs.toml is never part of a listed tree.

Removed

• The catalog-source readers (Breaking): method_source_to_contents, MethodFile, parse_method_files and serialize_method_files are gone with the fields they read; a method's files come back as MethodDetail.files.