tensoracle 0.5.1__tar.gz → 1.0.0__tar.gz

{tensoracle-0.5.1 → tensoracle-1.0.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: tensoracle
-Version: 0.5.1
+Version: 1.0.0
 Summary: Build, save, reuse, and execute TensorRT engines from safetensors weights
 Project-URL: documentation, https://sync-dev-org.github.io/tensoracle/
 Project-URL: repository, https://github.com/sync-dev-org/tensoracle
@@ -12,6 +12,7 @@ Classifier: Development Status :: 4 - Beta
 Classifier: Environment :: GPU :: NVIDIA CUDA :: 13
 Classifier: Intended Audience :: Developers
 Classifier: License :: OSI Approved :: MIT License
+Classifier: Operating System :: Microsoft :: Windows
 Classifier: Operating System :: POSIX :: Linux
 Classifier: Programming Language :: Python :: 3.12
 Classifier: Programming Language :: Python :: 3.13
@@ -57,10 +58,12 @@ Choose the path that matches your work:
 | TensorRT 11 SDK | Not needed | Not needed | Native plugin build |
 | CMake 3.20 or later and C++17 compiler | Not needed | Not needed | Native plugin build |
 
-The supported targets are Linux x86_64 (including WSL2), TensorRT 11, and GPU generations sm86, sm89, and sm120. The producer and native build tools are separate from the `tensoracle` runtime dependencies. Engine building, engine reuse, output comparison, and cubin production do not require torch. Converting `.pth` checkpoints requires the `convert` extra described below.
+The supported targets are Linux x86_64 (including WSL2) and Windows x86_64, TensorRT 11, and GPU generations sm86, sm89, and sm120. The same `py3-none-any` wheel installs on both operating systems. Cubin production with `tensoracle[producer]` runs on Linux; cubins do not depend on the OS, so a plugin DLL built on Windows can embed cubins produced on Linux. The producer and native build tools are separate from the `tensoracle` runtime dependencies. Engine building, engine reuse, output comparison, and cubin production do not require torch. Converting `.pth` checkpoints requires the `convert` extra described below.
 
 Follow the [four-stage optimization workflow](https://github.com/sync-dev-org/tensoracle/blob/main/docs/optimization.md) to establish output quality, evaluate lower precision and plugins, and measure speed.
 
+Follow [Build a C++ and Python repository](https://sync-dev-org.github.io/tensoracle/cpp-python-repositories/) for source layout, development environments, bindings, and Linux wheel packaging.
+
 ## Convert a PyTorch checkpoint
 
 Install the conversion extra in the environment where you prepare weights:
@@ -139,7 +142,7 @@ handle = open_engine(
 engine = handle.engine  # Keep handle.runtime alive while using the engine.
 ```
 
-Saved files live in the `tensoracle` directory under `XDG_CACHE_HOME`, or under `~/.cache` when that variable is unset. The cache identity includes the contents of all declared safetensors weight files and optional `plugins` files, the engine name, graph version, input shapes, builder settings, GPU product name, OS, CPU architecture, and TensorRT version. Raise `graph_version` when graph code changes; without a version change, the previous engine is reused. Use a different `name` or `graph_version` for engines with different tensor types, such as fp32 and fp16. Include in `graph_version` any other caller value that changes the engine contents but is not part of the cache identity, such as a plugin manifest or a build recipe. Pass `force_rebuild=True` to replace a cached engine even when it is intact.
+Saved files live in the `tensoracle` directory under `XDG_CACHE_HOME`, or under the home directory's `.cache` when that variable is unset. The same rule applies on every OS; on Windows the home directory is `%USERPROFILE%`, so the default is `%USERPROFILE%\.cache\tensoracle`. The cache identity includes the contents of all declared safetensors weight files and optional `plugins` files, the engine name, graph version, input shapes, builder settings, GPU product name, OS, CPU architecture, and TensorRT version. Raise `graph_version` when graph code changes; without a version change, the previous engine is reused. Use a different `name` or `graph_version` for engines with different tensor types, such as fp32 and fp16. Include in `graph_version` any other caller value that changes the engine contents but is not part of the cache identity, such as a plugin manifest or a build recipe. Pass `force_rebuild=True` to replace a cached engine even when it is intact. tensoracle closes a saved engine file after reading it, so another process using an opened engine does not block replacement. On Windows, a process that keeps the saved file itself open prevents replacement or removal with `PermissionError`; after that process closes the file, a file left empty by the failed rebuild is rejected as `CorruptEngineError` and can be rebuilt with `force_rebuild=True`.
 
 `plugins` names native TensorRT plugin libraries. Both `open_engine` and `build_serialized_engine` accept it. Each function checks that every library exports `getCreators`, loads it through TensorRT's registry, and retains it for the process before building the graph or deserializing an engine. Repeating the same library does not register it twice. `open_engine` also hashes the loaded library bytes into the engine identity; a changed library selects a different saved engine in a new process. A missing, unreadable, or incompatible library, or a library changed after loading in the same process, raises `PluginLibraryError` before a cached plan is opened. Keep the library and its cubin bundle together in the caller's wheel.
 
@@ -319,7 +322,17 @@ The example was also built with an older compiler and CUDA toolkit:
 | --- | --- | --- | --- |
 | gcc 13.3.0 / CMake 4.2.3 / CUDA toolkit 12.9.86 / TensorRT SDK 11.2.1.2 | `build` and a separate-process `reuse` with TensorRT runtime 11.2.1.2 on sm86 succeeded with zero outputs outside tolerance and both variants launched | 3.13.7 | WSL2 / glibc 2.39 |
 
-Each GPU subprocess had a 50-second limit. Speed was not measured. Native Linux, other kernels, and TensorRT 11 versions not listed here have not been tested.
+Each GPU subprocess had a 50-second limit. Speed was not measured.
+
+On 2026-10-18, the test suite and a native plugin build were run on Windows:
+
+| GPU | Result | Python | OS / NVIDIA driver / build tools / TensorRT |
+| --- | --- | --- | --- |
+| NVIDIA RTX 6000 Ada Generation (sm89) | `pytest`: 246 passed, 20 skipped (Linux-only memory checks and optional `convert` and `producer` dependencies) | 3.12.11 | Windows 11 Pro x64 build 26200 / 596.72 / Visual Studio 2022 (MSVC 19.44), CMake 3.31.6, Ninja, CUDA toolkit 12.8.93 / runtime and SDK 11.4.0.106 |
+
+On Windows, the standalone `cpp/` build and CTest passed, the CMake helper built the example plugin DLL against `nvinfer_11.lib`, and the plugin engine was built and reused in a separate process. The `py3-none-any` wheel built on Linux was installed unchanged on Windows. With `PATH` reduced to the Windows system directories and no CUDA or TensorRT SDK paths, the driver's `nvcuda.dll` and the pip-installed TensorRT runtime were sufficient to build and reuse engines.
+
+Native Linux, other kernels, Windows with sm86 or sm120, and TensorRT 11 versions not listed here have not been tested.
 
 ## Compare output arrays
 

{tensoracle-0.5.1 → tensoracle-1.0.0}/README.md

@@ -27,10 +27,12 @@ Choose the path that matches your work:
 | TensorRT 11 SDK | Not needed | Not needed | Native plugin build |
 | CMake 3.20 or later and C++17 compiler | Not needed | Not needed | Native plugin build |
 
-The supported targets are Linux x86_64 (including WSL2), TensorRT 11, and GPU generations sm86, sm89, and sm120. The producer and native build tools are separate from the `tensoracle` runtime dependencies. Engine building, engine reuse, output comparison, and cubin production do not require torch. Converting `.pth` checkpoints requires the `convert` extra described below.
+The supported targets are Linux x86_64 (including WSL2) and Windows x86_64, TensorRT 11, and GPU generations sm86, sm89, and sm120. The same `py3-none-any` wheel installs on both operating systems. Cubin production with `tensoracle[producer]` runs on Linux; cubins do not depend on the OS, so a plugin DLL built on Windows can embed cubins produced on Linux. The producer and native build tools are separate from the `tensoracle` runtime dependencies. Engine building, engine reuse, output comparison, and cubin production do not require torch. Converting `.pth` checkpoints requires the `convert` extra described below.
 
 Follow the [four-stage optimization workflow](https://github.com/sync-dev-org/tensoracle/blob/main/docs/optimization.md) to establish output quality, evaluate lower precision and plugins, and measure speed.
 
+Follow [Build a C++ and Python repository](https://sync-dev-org.github.io/tensoracle/cpp-python-repositories/) for source layout, development environments, bindings, and Linux wheel packaging.
+
 ## Convert a PyTorch checkpoint
 
 Install the conversion extra in the environment where you prepare weights:
@@ -109,7 +111,7 @@ handle = open_engine(
 engine = handle.engine  # Keep handle.runtime alive while using the engine.
 ```
 
-Saved files live in the `tensoracle` directory under `XDG_CACHE_HOME`, or under `~/.cache` when that variable is unset. The cache identity includes the contents of all declared safetensors weight files and optional `plugins` files, the engine name, graph version, input shapes, builder settings, GPU product name, OS, CPU architecture, and TensorRT version. Raise `graph_version` when graph code changes; without a version change, the previous engine is reused. Use a different `name` or `graph_version` for engines with different tensor types, such as fp32 and fp16. Include in `graph_version` any other caller value that changes the engine contents but is not part of the cache identity, such as a plugin manifest or a build recipe. Pass `force_rebuild=True` to replace a cached engine even when it is intact.
+Saved files live in the `tensoracle` directory under `XDG_CACHE_HOME`, or under the home directory's `.cache` when that variable is unset. The same rule applies on every OS; on Windows the home directory is `%USERPROFILE%`, so the default is `%USERPROFILE%\.cache\tensoracle`. The cache identity includes the contents of all declared safetensors weight files and optional `plugins` files, the engine name, graph version, input shapes, builder settings, GPU product name, OS, CPU architecture, and TensorRT version. Raise `graph_version` when graph code changes; without a version change, the previous engine is reused. Use a different `name` or `graph_version` for engines with different tensor types, such as fp32 and fp16. Include in `graph_version` any other caller value that changes the engine contents but is not part of the cache identity, such as a plugin manifest or a build recipe. Pass `force_rebuild=True` to replace a cached engine even when it is intact. tensoracle closes a saved engine file after reading it, so another process using an opened engine does not block replacement. On Windows, a process that keeps the saved file itself open prevents replacement or removal with `PermissionError`; after that process closes the file, a file left empty by the failed rebuild is rejected as `CorruptEngineError` and can be rebuilt with `force_rebuild=True`.
 
 `plugins` names native TensorRT plugin libraries. Both `open_engine` and `build_serialized_engine` accept it. Each function checks that every library exports `getCreators`, loads it through TensorRT's registry, and retains it for the process before building the graph or deserializing an engine. Repeating the same library does not register it twice. `open_engine` also hashes the loaded library bytes into the engine identity; a changed library selects a different saved engine in a new process. A missing, unreadable, or incompatible library, or a library changed after loading in the same process, raises `PluginLibraryError` before a cached plan is opened. Keep the library and its cubin bundle together in the caller's wheel.
 
@@ -289,7 +291,17 @@ The example was also built with an older compiler and CUDA toolkit:
 | --- | --- | --- | --- |
 | gcc 13.3.0 / CMake 4.2.3 / CUDA toolkit 12.9.86 / TensorRT SDK 11.2.1.2 | `build` and a separate-process `reuse` with TensorRT runtime 11.2.1.2 on sm86 succeeded with zero outputs outside tolerance and both variants launched | 3.13.7 | WSL2 / glibc 2.39 |
 
-Each GPU subprocess had a 50-second limit. Speed was not measured. Native Linux, other kernels, and TensorRT 11 versions not listed here have not been tested.
+Each GPU subprocess had a 50-second limit. Speed was not measured.
+
+On 2026-10-18, the test suite and a native plugin build were run on Windows:
+
+| GPU | Result | Python | OS / NVIDIA driver / build tools / TensorRT |
+| --- | --- | --- | --- |
+| NVIDIA RTX 6000 Ada Generation (sm89) | `pytest`: 246 passed, 20 skipped (Linux-only memory checks and optional `convert` and `producer` dependencies) | 3.12.11 | Windows 11 Pro x64 build 26200 / 596.72 / Visual Studio 2022 (MSVC 19.44), CMake 3.31.6, Ninja, CUDA toolkit 12.8.93 / runtime and SDK 11.4.0.106 |
+
+On Windows, the standalone `cpp/` build and CTest passed, the CMake helper built the example plugin DLL against `nvinfer_11.lib`, and the plugin engine was built and reused in a separate process. The `py3-none-any` wheel built on Linux was installed unchanged on Windows. With `PATH` reduced to the Windows system directories and no CUDA or TensorRT SDK paths, the driver's `nvcuda.dll` and the pip-installed TensorRT runtime were sufficient to build and reuse engines.
+
+Native Linux, other kernels, Windows with sm86 or sm120, and TensorRT 11 versions not listed here have not been tested.
 
 ## Compare output arrays
 

{tensoracle-0.5.1 → tensoracle-1.0.0}/cpp/cmake/TensoracleCubinPlugin.cmake

@@ -10,7 +10,11 @@ function(tensoracle_add_cubin_plugin)
     find_package(CUDAToolkit REQUIRED)
     find_path(TENSORACLE_NVINFER_INCLUDE NvInfer.h
         PATHS "${ARG_TENSORRT_ROOT}/include" NO_DEFAULT_PATH REQUIRED)
-    find_library(TENSORACLE_NVINFER_LIBRARY NAMES nvinfer
+    set(_tensoracle_nvinfer_names nvinfer)
+    if(WIN32)
+        list(PREPEND _tensoracle_nvinfer_names nvinfer_11)
+    endif()
+    find_library(TENSORACLE_NVINFER_LIBRARY NAMES ${_tensoracle_nvinfer_names}
         PATHS "${ARG_TENSORRT_ROOT}/lib" "${ARG_TENSORRT_ROOT}/lib64"
         NO_DEFAULT_PATH REQUIRED)
 

tensoracle-1.0.0/docs/cpp-python-repositories.md

@@ -0,0 +1,199 @@
+# Build a C++ and Python repository
+
+Use this guide to organize a repository with a standalone C++ library and a Python package, then build and inspect its Linux wheels. Keep the C++ build independent of Python, put the Python project in its own directory, and make the package build collect the files it needs from those sources. The binding and wheel examples below illustrate a package named `example`; adapt the target names and dependencies to your project.
+
+## 1. Separate the language projects
+
+Keep `cpp/` and `python/` at the repository root:
+
+```text
+README.md
+LICENSE
+docs/
+cpp/
+  CMakeLists.txt
+  include/
+  src/
+  tests/
+  bindings.cpp          # Optional Python binding source
+python/
+  pyproject.toml
+  uv.lock
+  CMakeLists.txt        # Only when the Python build compiles an extension
+  src/
+    example/
+      __init__.py
+  tests/
+```
+
+`cpp/` owns the C++ sources, headers, CMake targets, and CTest tests. Its standalone configuration builds and tests the C++ library without discovering Python or nanobind. The Python build can compile `bindings.cpp` separately and link it to that library.
+
+`python/` is the Python project root. It owns package metadata, runtime dependencies, development dependencies, the lockfile, and the src-layout package. Run the project's uv commands there. Keep repository-wide documentation, the license, and examples at the repository root; keep `pyproject.toml`, Python tests, and the Python environment under `python/`.
+
+Keep one editable copy of each source file. Configure the package build to collect C++ sources or compiled libraries into the package as appropriate. A build that uses sibling `cpp/` files must also make those files available when building from a source distribution: stage a complete source tree or arrange an equivalent archive layout, then verify a build from the extracted archive.
+
+Tensoracle is an example of source packaging: its wheel includes the shared C++ headers, sources, and CMake helpers under `tensoracle/cpp/`, and the caller compiles its own plugin. Tensoracle's wheel contains no native binaries and uses `py3-none-any`. A repository that builds a Python extension needs the additional steps in sections 4–6.
+
+## 2. Keep development tools in the appropriate environment
+
+Create the Python environment at `python/.venv`, alongside `python/pyproject.toml` and `python/uv.lock`; keep the repository root free of a second `.venv`. uv uses a project-local [virtual environment](https://docs.astral.sh/uv/concepts/projects/layout/#the-project-environment). For this layout, start from the repository root and run:
+
+```bash
+cd python
+uv sync
+```
+
+Declare Python development tools such as pytest, Ruff, and a type checker in the Python project's development dependency group. Keep runtime dependencies in the `[project]` table's `dependencies` field, optional runtime features in extras, and isolated build requirements in the `[build-system]` table's `requires` field.
+
+Keep one CMake and one Ninja installation on the host's `PATH`, shared by standalone C++ builds and tests that invoke CMake. Do not add `cmake` or `ninja` to each project's Python development dependency group. Their installation method can follow the developer's platform and package manager.
+
+Each CMake entry point declares its minimum supported version with [`cmake_minimum_required`](https://cmake.org/cmake/help/latest/command/cmake_minimum_required.html). The host installation must meet all projects' minimums. Tensoracle's standalone C++ project requires CMake 3.20; the binding example below uses CMake 3.26 for `Development.SABIModule`. Verify affected C++ builds before upgrading a shared host installation.
+
+An isolated wheel build has separate requirements. Keep any CMake requirement it needs in `[build-system] requires`; that environment does not replace the host tools. [scikit-build-core](https://scikit-build-core.readthedocs.io/en/stable/configuration/index.html#cmake-and-ninja-minimum-versions) can obtain CMake or Ninja when the available versions do not satisfy its configuration.
+
+## 3. Test each language and identify GPU tests
+
+Run pytest from `python/` so that the Python project's configuration and environment apply:
+
+```bash
+uv run pytest
+uv run pytest -m "not gpu"
+```
+
+Register a `gpu` marker in the pytest configuration and apply `@pytest.mark.gpu` to tests that need a GPU. Use strict marker checking to catch misspelled markers. The second command selects tests that can run without a GPU; those tests must also avoid GPU initialization during collection. See [pytest's marker documentation](https://docs.pytest.org/en/stable/how-to/mark.html).
+
+Register the standalone C++ tests with CTest, using `include(CTest)` and `add_test`. From the repository root, configure and run them without activating the Python environment:
+
+```bash
+cmake -S cpp -B build/cpp -G Ninja -DBUILD_TESTING=ON
+cmake --build build/cpp
+ctest --test-dir build/cpp --output-on-failure
+ctest --test-dir build/cpp --output-on-failure -LE gpu
+```
+
+Supply any required SDK or toolchain paths at configuration time. Python independence does not remove C++ library, header, or CUDA toolkit prerequisites. For TensorRT plugins, follow [Prepare a TensorRT SDK](tensorrt-sdk.md).
+
+Give GPU-dependent CTest tests a [`gpu` label](https://cmake.org/cmake/help/latest/prop_test/LABELS.html); the final command excludes that label. A machine without a CUDA toolkit may also need a configuration that omits GPU targets. Test C++ library behavior through CTest and Python imports, bindings, and integration through pytest. Before distributing a wheel, install it into a clean environment and test the installed package outside the source tree.
+
+## 4. Install nanobind extensions inside the package
+
+Keep the standalone library's CMake configuration independent of the Python bindings. The Python project's CMake configuration discovers Python and nanobind, adds the C++ library, and installs the extension into the Python package. For a C++ target named `example_core`, these fragments illustrate that arrangement.
+
+In `python/pyproject.toml`, alongside the project's metadata:
+
+```toml
+[build-system]
+requires = ["scikit-build-core", "nanobind"]
+build-backend = "scikit_build_core.build"
+
+[tool.scikit-build]
+wheel.packages = ["src/example"]
+wheel.py-api = "cp312"
+```
+
+In `python/CMakeLists.txt`:
+
+```cmake
+cmake_minimum_required(VERSION 3.26)
+project(example_python LANGUAGES CXX)
+
+find_package(Python 3.12 REQUIRED COMPONENTS
+    Interpreter Development.Module Development.SABIModule)
+find_package(nanobind CONFIG REQUIRED)
+
+add_subdirectory(../cpp cpp)
+set_target_properties(example_core PROPERTIES POSITION_INDEPENDENT_CODE ON)
+nanobind_add_module(_native STABLE_ABI ../cpp/bindings.cpp)
+target_link_libraries(_native PRIVATE example_core)
+install(TARGETS _native LIBRARY DESTINATION example)
+```
+
+The binding source declares `NB_MODULE(_native, m)`, and `python/src/example/__init__.py` imports from `._native`. The installed wheel contains `example/__init__.py` and the extension, such as `example/_native.abi3.so`. The snippets assume that `cpp/CMakeLists.txt` defines `example_core` and that the package build supplies the sibling C++ sources as described in section 1. See [nanobind packaging](https://nanobind.readthedocs.io/en/latest/packaging.html) for the binding build and installation mechanism.
+
+For nanobind's linked build mode, [`STABLE_ABI`](https://nanobind.readthedocs.io/en/latest/api_cmake.html#command:nanobind_add_module) requires Python 3.12 or later. Pair it with `wheel.py-api = "cp312"` so that the binary and wheel metadata agree. This produces a CPython stable-ABI extension for compatible GIL-enabled Python versions from that floor, subject to the package's `requires-python`. It does not remove platform, C++ ABI, or runtime library constraints. Free-threaded Python needs its own build and compatibility decisions.
+
+Read the three parts of the [wheel compatibility tag](https://packaging.python.org/en/latest/specifications/platform-compatibility-tags/) separately:
+
+| Wheel contents | Example Python–ABI–platform tag |
+| --- | --- |
+| Python and source files, without native binaries | `py3-none-any` |
+| Native libraries that do not use the Python C API | `py3-none-manylinux_2_28_x86_64` |
+| A CPython stable-ABI extension with a Python 3.12 floor | `cp312-abi3-manylinux_2_28_x86_64` |
+| A CPython 3.12 extension using its version-specific ABI | `cp312-cp312-manylinux_2_28_x86_64` |
+
+These are illustrative targets, not tags to assign before inspecting the binaries. `none` describes the Python ABI; a wheel carrying a shared library still needs a platform tag. `abi3` retains a minimum Python version and does not mean every Python implementation or build is supported.
+
+## 5. Check manylinux compatibility before uploading to PyPI
+
+For glibc-based Linux x86_64 wheels, use a supported manylinux platform tag. PyPI's [platform validation](https://github.com/pypi/warehouse/blob/main/warehouse/utils/wheel.py) rejects the generic `linux_x86_64` tag. Under [PEP 600](https://peps.python.org/pep-0600/), `manylinux_2_28_x86_64` promises compatibility with mainstream x86_64 Linux systems using glibc 2.28 or later. It does not describe CUDA or GPU driver requirements; document those separately.
+
+The actual minimum follows the symbols and libraries used by the built artifacts. Linking on a newer system can introduce newer glibc requirements even when the source code has not changed. The host's glibc version alone is not a measurement of the wheel's minimum, and changing the filename cannot lower that minimum. Inspect required `GLIBC_*` versions, along with `GLIBCXX_*` and `CXXABI_*` requirements for the C++ runtime.
+
+Run [`auditwheel show`](https://github.com/pypa/auditwheel) in the build container. Extract the wheel and inspect its ELF files with [`readelf`](https://sourceware.org/binutils/docs/binutils/readelf.html). For example, after setting `WHEEL` to the exact wheel path and choosing a new extraction directory:
+
+```bash
+auditwheel show "$WHEEL"
+python -m zipfile -e "$WHEEL" wheel-inspect
+LC_ALL=C readelf --version-info --wide wheel-inspect/example/_native.abi3.so
+LC_ALL=C readelf --dynamic --wide wheel-inspect/example/_native.abi3.so
+```
+
+Repeat the ELF checks for every shared library and executable in the wheel, including nested dependencies. Inspect the version requirements and `NEEDED`, `RPATH`, and `RUNPATH` entries. Use `LC_ALL=C` when tools or scripts rely on English output headings, and compare numeric version components rather than sorting version strings lexically. Rebuild in an appropriate environment if a required symbol exceeds the intended baseline; auditwheel cannot repair an overly new glibc or libstdc++ dependency.
+
+### Shared libraries and search paths
+
+Assign each shipped shared library to one package. If another wheel supplies a library, declare that package as a runtime dependency and arrange a documented runtime lookup path. Do not copy its library into the consuming wheel. RAPIDS publishes separate [Python binding](https://pypi.org/project/pylibcudf-cu12/) and [C++ library](https://pypi.org/project/libcudf-cu12/) distributions as `pylibcudf-cu12` and `libcudf-cu12`; their release files illustrate the distinction between Python ABI tags and platform tags.
+
+`auditwheel repair` normally copies non-policy shared libraries into the wheel and changes their search paths. Review that list before repair, and exclude libraries owned by dependency wheels and libraries provided by the GPU driver. An exclusion does not establish manylinux compliance. Resolve and test those dependencies separately, and inspect the final wheel again. Also test libraries loaded through `dlopen` or `ctypes`, which auditwheel cannot discover from `NEEDED` entries alone.
+
+Use `$ORIGIN`-relative ELF search paths, where `$ORIGIN` is the directory containing the referencing binary. For an extension whose own package contains a `lib/` subdirectory, a CMake target can use:
+
+```cmake
+set_target_properties(_native PROPERTIES
+    BUILD_RPATH_USE_ORIGIN ON
+    INSTALL_RPATH "$ORIGIN/lib")
+```
+
+[`INSTALL_RPATH`](https://cmake.org/cmake/help/latest/prop_tgt/INSTALL_RPATH.html) controls the installed artifact; `BUILD_RPATH_USE_ORIGIN` applies to build-tree paths. Select the relative path for the actual installed layout, including dependency packages where needed, and check every library's own dependencies. Remove absolute build-machine paths, including paths introduced by imported CMake targets. Keep `$ORIGIN` literal when passing a value through a shell.
+
+Keep NVIDIA driver libraries such as `libcuda.so.1`, `libnvidia-encode.so.1`, and `libnvcuvid.so.1` outside the wheel. The target system supplies the compatible driver. Link-time SDK stubs must also stay out of the runtime package and its search paths; NVIDIA's [Video Codec SDK instructions](https://docs.nvidia.com/video-technologies/video-codec-sdk/13.0/read-me/index.html) distinguish these stubs from the installed driver. Treat CUDA runtime libraries separately, using an appropriate static runtime or declared runtime package dependencies for the chosen toolkit.
+
+Check artifact size before upload. PyPI's [default individual file limit](https://docs.pypi.org/project-management/storage-limits/) is 100 MB; projects can have an approved increase. Installing and testing the final wheel with only its declared dependencies is still necessary after tag and ELF inspection.
+
+## 6. Record the wheel build environment
+
+Build release wheels in a [manylinux container](https://github.com/pypa/manylinux) for the intended architecture and compatibility floor. For example, `quay.io/pypa/manylinux_2_28_x86_64` provides a glibc 2.28 baseline. Select compiler, SDK, CUDA toolkit, and dependency versions that can build and run against that baseline. A recent compiler does not require building against a recent host glibc.
+
+Pin the image by an immutable [image digest](https://docs.docker.com/reference/cli/docker/image/pull/#pull-an-image-by-digest-immutable-identifier), using `image@sha256:<digest>` with the actual digest of the selected image. A moving tag is useful for discovering updates but does not identify a repeatable build input. Pin any derived image as well, and record additional package installation inputs.
+
+Keep a build record with:
+
+- The source revision, patches, and source manifest.
+- The image reference, manifest digest, image configuration digest, and architecture.
+- The compiler, linker, CMake, Ninja, Python interpreter, and build backend versions.
+- The CUDA toolkit and SDK versions, when used, and relevant compiler or CMake options.
+- The resolved build and runtime dependencies, resulting wheel hashes, ELF inspection results, and test results.
+
+Build from clean inputs inside that container, inspect the final artifacts there, and test their installation in a separate runtime environment. When native C++ objects cross extension boundaries, align the C++ library ABI, compiler compatibility, debug mode, symbol visibility, and nanobind ABI. Python's stable ABI does not make incompatible C++ objects interchangeable. [nanobind's compatibility requirements](https://nanobind.readthedocs.io/en/latest/faq.html#how-can-i-avoid-conflicts-with-other-projects-using-nanobind) describe those constraints.
+
+## 7. Record and reconstruct upstream C++ sources
+
+When development needs a local copy of an upstream C++ project, copy the selected files into a dedicated directory and keep the source inputs explicit. Record the upstream URL and immutable revision, the selected paths, the ordered local patches, and the license information. Keep a SHA-256 manifest covering every file in the resulting source tree, including files added by patches.
+
+For example, a provenance directory can contain:
+
+```text
+upstream/library/
+  PROVENANCE.md
+  patches/
+  MANIFEST.sha256
+  fetch-and-verify.py
+```
+
+`PROVENANCE.md` identifies the upstream revision and explains the selection and patch order. `MANIFEST.sha256` records the expected relative paths and hashes after patching. The acquisition script reads these recorded inputs, retrieves the exact revision, selects the required files, applies the patches, and verifies the resulting tree. Keep the revision in one authoritative location that the script reads.
+
+Use ordinary copied files for the development tree, rather than a Git submodule. A submodule records a commit reference instead of ordinary source files, so a publication process that copies tracked files into a snapshot does not materialize that source tree. An explicit acquisition script also makes the build independent of recursive Git checkout behavior.
+
+Keep the copied upstream source tree out of the public repository. Publish the revision record, patches, complete file manifest, acquisition and verification script, and instructions for building and testing from the reconstructed sources. Preserve required license notices in the appropriate distributed artifacts. The public checkout must let another developer reconstruct the inputs and build the native components without access to the development copy.
+
+Verify both file contents and the complete set of paths: missing, changed, and unexpected files must fail verification. A checksum command that only checks listed files will not detect extra files by itself. Verify before configuring or compiling, and stop on a download, patch, or manifest failure. When updating upstream, regenerate the manifest from the reviewed source selection and rerun the native build and tests. If publishing a source distribution, ensure its documented acquisition process makes the same verified inputs available for its build.

{tensoracle-0.5.1 → tensoracle-1.0.0}/docs/index.md

@@ -4,6 +4,8 @@
 
 Follow the [four-stage optimization workflow](optimization.md) to establish output quality, evaluate lower precision and plugins, and measure speed.
 
+Follow [Build a C++ and Python repository](cpp-python-repositories.md) for source layout, development environments, bindings, and Linux wheel packaging.
+
 ## Terms
 
 - A **TensorRT engine** is an executable form of a model optimized for a GPU, precision, and TensorRT version. It can be kept in memory or saved to disk.
@@ -29,7 +31,7 @@ Follow the [four-stage optimization workflow](optimization.md) to establish outp
 | TensorRT 11 SDK | Not needed | Not needed | Native plugin build |
 | CMake 3.20 or later and C++17 compiler | Not needed | Not needed | Native plugin build |
 
-The supported platform is Linux x86_64 (including WSL2) with sm86, sm89, or sm120 GPUs and TensorRT 11. The producer and native build tools are separate from the `tensoracle` runtime dependencies. Engine building, engine reuse, output comparison, and cubin production do not require torch. Converting `.pth` checkpoints requires the `convert` extra.
+The supported platforms are Linux x86_64 (including WSL2) and Windows x86_64 with sm86, sm89, or sm120 GPUs and TensorRT 11. The same `py3-none-any` wheel installs on both operating systems. Cubin production with `tensoracle[producer]` runs on Linux; a plugin DLL built on Windows can embed cubins produced on Linux. The producer and native build tools are separate from the `tensoracle` runtime dependencies. Engine building, engine reuse, output comparison, and cubin production do not require torch. Converting `.pth` checkpoints requires the `convert` extra.
 
 ### Convert a PyTorch checkpoint
 
@@ -70,7 +72,7 @@ handle = open_engine(
 )
 ```
 
-`my_model` represents the application's model package. On a valid cache hit, `open_engine` does not call `graph`; on a miss, it builds and saves a new engine. Raise `graph_version` when the graph code changes or when any other caller value that changes the engine contents but is not part of the cache identity changes, such as a plugin manifest or a build recipe. `open_engine` itself does not execute the engine or manage GPU buffers. Create an execution unit from its returned handle to enqueue inference. Saved engines live under `XDG_CACHE_HOME/tensoracle`, or `~/.cache/tensoracle` when `XDG_CACHE_HOME` is unset. See the [complete cache example](https://github.com/sync-dev-org/tensoracle#save-and-reopen-an-engine) for the declaration and expected input and output types.
+`my_model` represents the application's model package. On a valid cache hit, `open_engine` does not call `graph`; on a miss, it builds and saves a new engine. Raise `graph_version` when the graph code changes or when any other caller value that changes the engine contents but is not part of the cache identity changes, such as a plugin manifest or a build recipe. `open_engine` itself does not execute the engine or manage GPU buffers. Create an execution unit from its returned handle to enqueue inference. Saved engines live under `XDG_CACHE_HOME/tensoracle`, or `~/.cache/tensoracle` when `XDG_CACHE_HOME` is unset. On Windows, `~` is `%USERPROFILE%`. See the [complete cache example](https://github.com/sync-dev-org/tensoracle#save-and-reopen-an-engine) for the declaration and expected input and output types.
 
 ### Execute an engine
 

{tensoracle-0.5.1 → tensoracle-1.0.0}/docs/precision.md

@@ -123,7 +123,7 @@ reference_handle = open_linear("fp32")
 candidate_handle = open_linear("bf16")  # Or "int8"; "fp8" on sm89/sm120.
 ```
 
-TF32 remains disabled by tensoracle, including for the fp32 reference. Engines are saved under `XDG_CACHE_HOME/tensoracle`, or `~/.cache/tensoracle`. Repeat the same call with unchanged build conditions in another process to reuse the plan without invoking the graph function. Keep the weight file and the engine names/versions stable across the restart. Follow [Execute an engine](index.md#execute-an-engine) to allocate fp32 input/output buffers and enqueue each handle with the same inputs.
+TF32 remains disabled by tensoracle, including for the fp32 reference. Engines are saved under `XDG_CACHE_HOME/tensoracle`, or `~/.cache/tensoracle` (`%USERPROFILE%\.cache\tensoracle` on Windows). Repeat the same call with unchanged build conditions in another process to reuse the plan without invoking the graph function. Keep the weight file and the engine names/versions stable across the restart. Follow [Execute an engine](index.md#execute-an-engine) to allocate fp32 input/output buffers and enqueue each handle with the same inputs.
 
 ## Compare outputs and choose limits
 

{tensoracle-0.5.1 → tensoracle-1.0.0}/docs/tensorrt-sdk.md

@@ -1,6 +1,6 @@
 # Prepare a TensorRT SDK
 
-Use this procedure to prepare the headers and `libnvinfer` needed to build a native cubin plugin on Linux x86_64, including WSL2. The SDK root contains 13 headers in `include/`, `lib/libnvinfer.so.11`, and a relative `lib/libnvinfer.so` symlink pointing to `libnvinfer.so.11`. The CUDA toolkit, CMake, and a C++17 compiler are separate build prerequisites. Normal engine reuse does not need this SDK root.
+Use the Linux procedure below to prepare the headers and `libnvinfer` needed to build a native cubin plugin on Linux x86_64, including WSL2. For Windows x86_64, use the [Windows procedure](#windows-x86_64). The Linux SDK root contains 13 headers in `include/`, `lib/libnvinfer.so.11`, and a relative `lib/libnvinfer.so` symlink pointing to `libnvinfer.so.11`. The CUDA toolkit, CMake, and a C++17 compiler are separate build prerequisites. Normal engine reuse does not need this SDK root.
 
 The inputs below are fixed for SDK **11.2.1.2**: headers from a release commit of [NVIDIA TensorRT OSS](https://github.com/NVIDIA/TensorRT), and the exact `tensorrt-cu13-libs` wheel from [NVIDIA's package index](https://pypi.nvidia.com/tensorrt-cu13-libs/). The wheel platform is `manylinux_2_28_x86_64`; use that file rather than an aarch64 or Windows wheel.
 
@@ -110,3 +110,90 @@ The tests also need the CUDA toolkit; tests marked `gpu` require an NVIDIA GPU a
 ## Use another TensorRT 11 release
 
 Use the same acquisition and verification steps for another TensorRT 11 release, but first establish its release commit, exact wheel filename and platform, expected wheel and library digests, and expected digests of every required header. Check that release's exact `NV_TENSORRT_MAJOR`, `MINOR`, `PATCH`, and `BUILD` values and library SONAME. The caller must verify and record those inputs; the 11.2.1.2 values above apply only to that SDK and cannot verify another release. Build and test the caller's plugin with the selected SDK and runtime.
+
+## Windows x86_64
+
+Use NVIDIA's official Windows ZIP to obtain both the headers and the MSVC import library. The TensorRT runtime wheel supplies DLLs, but it does not replace the SDK's `include/` directory and `lib/nvinfer_11.lib`. See NVIDIA's [Windows ZIP installation guide](https://docs.nvidia.com/deeplearning/tensorrt/latest/installing-tensorrt/install-zip.html) and [TensorRT 11 downloads](https://developer.nvidia.com/tensorrt/download/11x).
+
+The following inputs are fixed for **11.4.0.106**, Windows amd64, CUDA 13.4. Use Visual Studio 2022 with MSVC, CMake, Ninja, and a CUDA toolkit available in an **x64 Native Tools Command Prompt for VS 2022**, then start PowerShell from that prompt. The example below selects CUDA toolkit 12.8 as a build input; tensoracle's Python runtime dependencies select the CUDA 13 TensorRT runtime separately. Do not combine Windows import libraries with Linux shared libraries.
+
+Choose a new workspace. The command creating it must fail if the directory already exists. Download the fixed ZIP, record its digest, and extract it without installing software system-wide:
+
+```powershell
+$ErrorActionPreference = 'Stop'
+$SdkWork = Join-Path $env:USERPROFILE '.cache/tensoracle-sdk-11.4.0.106-windows'
+New-Item -ItemType Directory -Path $SdkWork | Out-Null
+Set-Location $SdkWork
+$ZipName = 'TensorRT-Enterprise-11.4.0.106-Windows-amd64-cuda-13.4-Release-external.zip'
+$Url = 'https://developer.download.nvidia.com/compute/machine-learning/tensorrt/11.4.0/zip/' + $ZipName
+Invoke-WebRequest -Uri $Url -OutFile $ZipName
+Get-FileHash -Algorithm SHA256 $ZipName | Format-List | Out-File archive-sha256.txt
+Expand-Archive -LiteralPath $ZipName -DestinationPath extracted
+$env:TENSORRT_ROOT = Join-Path $SdkWork 'extracted/TensorRT-11.4.0.106'
+```
+
+Verify the extracted build inputs against these SHA-256 values. These values identify the SDK members needed by the build, including the nested Python plugin header; they are not a digest of the whole ZIP. Stop on a mismatch rather than using an incomplete or mixed SDK:
+
+```powershell
+$Expected = @'
+64a59d5bfdb1dd0b7a6a98992d3b617d926b760a6134c09a8bec0e62227ff5ff lib/nvinfer_11.lib
+886f693c1d958651eeee58ed4d02c0f31da355c112102539d6bd4d567f56a3a4 include/NvOnnxConfig.h
+81fb4be15a2432bf45c858176e347e017a8f5d9a20d82225141cd263a5114c32 include/NvInfer.h
+870a47268d1d5e08dcb72b14157292a16ba541cc9d95327a860977aba11c759a include/NvInferPluginBase.h
+e5558eb96fc2b08a964f73ca096213a2bab9f356a897122f2c0c56a2a6553315 include/NvInferImpl.h
+7629d76e5a6bc1ee910ab90c117cdfa1f350349321e211cc9003dbad3f03b5ef include/NvInferRuntimePlugin.h
+7141cc8fc7d0274ba76c085a395b2be195b68d2ef205a381ddd41f8d0b323299 include/NvInferRuntime.h
+e8c04d3cd04fd3e6abdb95a3398d2bee5c171f86eb772b3b8f30f66d21006e9a include/NvInferRuntimeBase.h
+8b155e73287ca63e276fc55297ae5b8723888d925afbf63a392e908faede8e02 include/NvInferPluginUtils.h
+c28e2c4cbd8f1f0ed7ea6a4fe002906b92916abd3b778e71344649e522509b39 include/NvInferVersion.h
+6c30ffcd9c688bd286362aae3e00c0369961b78e7b0bffd08cae739f5d780ca1 include/NvInferRuntimeCommon.h
+3ab7107afc15e4317a17a57b31d7d42d677091380918bfc2dc45eb4ab38570ad include/NvInferPlugin.h
+440c0ea9cdfc8940d598daff766bc6db098b83d4250f7404c0930dd013ecd0eb include/NvOnnxParser.h
+99a80d98a7cdcac515d64a5f48dafe2a6d4f920c4513ec3f2b07bacf7c4ab09f include/NvInferLegacyDims.h
+2ee14ba7c2cf595af1d8f3ad33bc340fbadaa03a8e1bcea1bbfbe18235d965e7 include/impl/NvInferPythonPlugin.h
+'@
+$Expected -split "`n" | ForEach-Object {
+    $Digest, $Relative = $_.Trim() -split ' ', 2
+    $File = Join-Path $env:TENSORRT_ROOT $Relative
+    if ((Get-FileHash -Algorithm SHA256 -LiteralPath $File).Hash -ne $Digest) {
+        throw "SDK checksum differs: $Relative"
+    }
+}
+$Expected | Set-Content -Encoding ascii SHA256SUMS
+```
+
+Check the exact header version using MSVC's preprocessor. It must print `11`, `4`, `0`, and `106`, in that order; the import library's filename identifies only the major version:
+
+```powershell
+@'
+#include "NvInferVersion.h"
+NV_TENSORRT_MAJOR
+NV_TENSORRT_MINOR
+NV_TENSORRT_PATCH
+NV_TENSORRT_BUILD
+'@ | Set-Content -Encoding ascii version.cpp
+cl /nologo /EP /I "$env:TENSORRT_ROOT/include" version.cpp
+if ($LASTEXITCODE) { throw 'SDK version check failed' }
+```
+
+From the tensoracle repository root, configure and test the standalone C++ project, then build the example plugin wheel with the same verified SDK:
+
+```powershell
+$env:TENSORACLE_SDK_ROOT = $env:TENSORRT_ROOT
+$env:TENSORACLE_CUDA_ROOT = 'C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v12.8'
+cmake -S cpp -B build/windows -G Ninja -DCMAKE_BUILD_TYPE=Release `
+    "-DTENSORRT_ROOT=$env:TENSORRT_ROOT" "-DCUDAToolkit_ROOT=$env:TENSORACLE_CUDA_ROOT"
+if ($LASTEXITCODE) { throw 'CMake configuration failed' }
+cmake --build build/windows --config Release
+if ($LASTEXITCODE) { throw 'C++ build failed' }
+ctest --test-dir build/windows -C Release --output-on-failure
+if ($LASTEXITCODE) { throw 'CTest failed' }
+uv build examples/cubin_plugin --wheel `
+    "--config-setting=cmake.define.TENSORRT_ROOT=$env:TENSORRT_ROOT" `
+    "--config-setting=cmake.define.CUDAToolkit_ROOT=$env:TENSORACLE_CUDA_ROOT"
+if ($LASTEXITCODE) { throw 'Example wheel build failed' }
+uv run --project python pytest python/tests/test_example_plugin.py
+if ($LASTEXITCODE) { throw 'Example plugin tests failed' }
+```
+
+The example build uses `cpp/cmake/TensoracleCubinPlugin.cmake`, which finds `nvinfer_11.lib` in the SDK's `lib/` directory. The built plugin is a DLL. Keep its TensorRT runtime available through the application's installed Python dependencies; the SDK directory is a build input and does not need to be added to the runtime `PATH`. For another TensorRT 11 release, establish new expected digests and check that release's exact header version before building.

{tensoracle-0.5.1 → tensoracle-1.0.0}/mkdocs.yml

@@ -35,6 +35,7 @@ nav:
   - Optimization workflow: optimization.md
   - bf16, int8, and fp8 engines: precision.md
   - TensorRT SDK setup: tensorrt-sdk.md
+  - C++ and Python repositories: cpp-python-repositories.md
   - API reference:
       - Engine and comparison: api/index.md
       - Cubin bundle inspection: api/bundle.md

{tensoracle-0.5.1 → tensoracle-1.0.0}/pyproject.toml

@@ -12,6 +12,7 @@ classifiers = [
     "Intended Audience :: Developers",
     "License :: OSI Approved :: MIT License",
     "Operating System :: POSIX :: Linux",
+    "Operating System :: Microsoft :: Windows",
     "Programming Language :: Python :: 3.12",
     "Programming Language :: Python :: 3.13",
     "Topic :: Software Development :: Libraries",

{tensoracle-0.5.1 → tensoracle-1.0.0}/src/tensoracle/_version.py

@@ -18,7 +18,7 @@ version_tuple: tuple[int | str, ...]
 commit_id: str | None
 __commit_id__: str | None
 
-__version__ = version = '0.5.1'
-__version_tuple__ = version_tuple = (0, 5, 1)
+__version__ = version = '1.0.0'
+__version_tuple__ = version_tuple = (1, 0, 0)
 
 __commit_id__ = commit_id = None

{tensoracle-0.5.1 → tensoracle-1.0.0}/src/tensoracle/bundle.py

@@ -4,7 +4,7 @@ import hashlib
 import json
 import struct
 import tempfile
-from pathlib import Path
+from pathlib import Path, PurePosixPath, PureWindowsPath
 from zipfile import ZipFile
 
 from ._plugins import PluginLibraryError, exported_data
@@ -125,6 +125,18 @@ def _validate_entry(entry: dict) -> None:
         raise BundleError("unsupported floating point specialization rule")
 
 
+def _relative_path(name: str) -> bool:
+    posix = PurePosixPath(name)
+    windows = PureWindowsPath(name)
+    return not (
+        posix.is_absolute()
+        or windows.drive
+        or windows.root
+        or ".." in posix.parts
+        or ".." in windows.parts
+    )
+
+
 def inspect_bundle(root: Path, *, plugin: Path | None = None) -> str:
     """Verify cubin bytes, ELF SM, supported launch metadata, and plugin identity."""
     root = Path(root)
@@ -144,7 +156,7 @@ def inspect_bundle(root: Path, *, plugin: Path | None = None) -> str:
             raise BundleError("invalid cubin entry")
         _validate_entry(entry)
         name = entry.get("file")
-        if not isinstance(name, str) or Path(name).is_absolute() or ".." in Path(name).parts:
+        if not isinstance(name, str) or not _relative_path(name):
             raise BundleError("invalid cubin path")
         if name in visited:
             raise BundleError("duplicate cubin path")
@@ -189,9 +201,9 @@ def inspect_wheel(path: Path, *, plugin: str | None = None) -> str:
     with tempfile.TemporaryDirectory() as directory, ZipFile(path) as archive:
         root = Path(directory)
         for info in archive.infolist():
-            member = Path(info.filename)
-            if member.is_absolute() or ".." in member.parts:
+            if not _relative_path(info.filename):
                 raise BundleError("wheel contains an invalid path")
+            member = Path(info.filename)
             if info.is_dir():
                 continue
             destination = root / member
@@ -200,7 +212,7 @@ def inspect_wheel(path: Path, *, plugin: str | None = None) -> str:
         manifests = list(root.rglob("bundle.json"))
         if len(manifests) != 1:
             raise BundleError("wheel must contain exactly one cubin bundle")
-        library = root / plugin if plugin is not None else None
-        if library is not None and (Path(plugin).is_absolute() or ".." in Path(plugin).parts):
+        if plugin is not None and not _relative_path(plugin):
             raise BundleError("invalid plugin path in wheel")
+        library = root / plugin if plugin is not None else None
         return inspect_bundle(manifests[0].parent, plugin=library)

{tensoracle-0.5.1 → tensoracle-1.0.0}/tests/cubin_io/check.cpp

@@ -5,6 +5,10 @@
 #include <stdexcept>
 #include <utility>
 
+#if defined(NDEBUG)
+#error "The native IO contract requires active assertions"
+#endif
+
 using namespace nvinfer1;
 using namespace tensoracle::cubin;
 

{tensoracle-0.5.1 → tensoracle-1.0.0}/tests/example_runtime.py

@@ -111,7 +111,7 @@ def _control():
     sm = f"sm{properties.major * 10 + properties.minor}"
     entry = next(item for item in manifest["entries"] if item["id"] == f"{sm}.dot.tf32-control")
     image = (library_path().parent / "bundle" / entry["file"]).read_bytes()
-    driver = ctypes.CDLL("libcuda.so.1")
+    driver = ctypes.CDLL("nvcuda.dll" if sys.platform == "win32" else "libcuda.so.1")
 
     def call(name, *args):
         method = getattr(driver, name)
@@ -192,7 +192,7 @@ def _control():
 
 def _separate_cuda_contexts():
     """Reopen the cached plan in two owner contexts at the same time."""
-    driver = ctypes.CDLL("libcuda.so.1")
+    driver = ctypes.CDLL("nvcuda.dll" if sys.platform == "win32" else "libcuda.so.1")
 
     def call(name, *args):
         method = getattr(driver, name)
@@ -229,7 +229,7 @@ def _duplicate_creator(directory):
     register_libraries((original,))
     registry = trt.get_plugin_registry()
     assert registry.get_creator("TensoracleExampleDot", "1", "tensoracle.example") is not None
-    changed = Path(directory) / "same-creators-changed-bytes.so"
+    changed = Path(directory) / f"same-creators-changed-bytes{original.suffix}"
     shutil.copyfile(original, changed)
     with changed.open("ab") as stream:
         stream.write(b"different bytes with the same creators")