Python Plugin Packaging and Runtime Architecture

Full report

On this page

1. Executive Recommendation

\[Proposal\] The analysis concludes that a C\# Windows desktop application must adopt an isolated, out-of-process Python plugin architecture, categorically rejecting embedded interpreter models. The host application should bundle a portable, host-managed CPython distribution and utilize the Rust-based uv package manager to orchestrate per-plugin virtual environments. This ensures deterministic, locked, and high-speed offline installations without relying on the end user's system state. \[Architecture synthesis\] Python plugins must be distributed exclusively as pre-compiled standard Wheels (.whl), strictly omitting source distributions (.tar.gz) to eliminate install-time build vulnerabilities and uncontrolled compiler dependencies. For process isolation and inter-process communication (IPC), the host must spawn sidecar Python processes constrained by Windows Job Objects to guarantee absolute lifecycle termination. IPC must be implemented via asynchronous Windows Named Pipes with explicit Access Control Lists (ACLs), transferring length-prefixed JSON payloads. This architectural direction eliminates Global Interpreter Lock (GIL) contention within the C\# UI thread, contains third-party crashes, and provides a clear pathway toward deploying high-security plugins within a Less Privileged AppContainer (LPAC).

2. Scope, Assumptions, and Zero-Access Declaration

\[Architecture synthesis\] This report defines a secure and robust Python runtime isolation architecture on Windows. It is predicated on the owner-supplied context that the host application requires resilience against unstable third-party Python code, dependency contamination, ambiguous runtime selections, and malicious actions. The architecture assumes that plugins require independent lifecycles—including installation, updating, disabling, and clean uninstallation—without impacting the host or sibling plugins. \[Proposal\] Zero-Access Declaration: The analysis and architecture formulated herein represent pure external research. No internal telemetry, private repositories, proprietary product binaries, endpoints, or unreleased roadmaps were accessed. The generic architecture utilizes neutral, synthetic data for all examples and code blocks. Recommendations are strictly derived from Python standard specifications, Microsoft Windows internal documentation, and modern packaging toolchains.

3. Source Method and Python-Version Applicability

\[Platform fact\] The architectural guidelines in this report target modern Python environments, specifically Python 3.12 and Python 3.13, utilizing asynchronous features and packaging standards stabilized in recent CPython releases. Research prioritizes Python Packaging Authority (PyPA) guidelines, including PEP 621 for Project Metadata, PEP 427 for Wheel Binary Format, and PEP 376 for the Database of Installed Python Distributions1. Windows operating system security paradigms rely heavily on Win32 API documentation pertaining to Job Objects, Security Identifiers (SIDs), Access Control Lists, and AppContainer isolation mechanics4.

4. Packaging and Discovery

\[Specification\] The Python ecosystem relies on standardized packaging metadata to orchestrate discovery, dependency resolution, and execution. The pyproject.toml file serves as the canonical source for declaring static and dynamic project metadata, encompassing dependency constraints, optional features, and entry points1. Wheels (.whl), which are structured ZIP archives, encapsulate the executable code alongside a .dist-info directory conforming to PEP 376 and PEP 4272. This directory houses the METADATA file containing core package information, the RECORD file maintaining cryptographic hashes of all files for integrity verification and uninstallation, and the entry\_points.txt file exposing discoverable component hooks2. Environment markers and platform tags within the wheel filename (e.g., cp313-cp313-win\_amd64) are heavily utilized to enforce exact ABI, architecture, and Python version compatibility prior to installation3. \[Proposal\] A submitted plugin artifact must be a composite archive containing a standard pure-Python or native Wheel, a deterministic lockfile (such as uv.lock), and a host-specific JSON manifest declaring host capabilities, minimum contract versions, and required permissions. Submitting source distributions (.tar.gz) is strictly prohibited, as they allow arbitrary code execution via setup.py during the build phase and introduce reliance on local C++ build tools. Distributing standalone executables generated by tools like PyInstaller or Nuitka is similarly rejected due to the immense disk overhead of bundling full interpreters per plugin, the inability of the host to patch the interpreter centrally, and the opacity of compiled binaries to standard supply-chain scanning. \[External guidance\] To prevent malicious or accidental code execution during catalog discovery, the host application must never invoke importlib.metadata or execute the plugin to identify its capabilities. Because a Wheel is intrinsically a standard ZIP file, the C\# host must programmatically open the .whl archive and parse the entry\_points.txt inside the .dist-info directory3. This methodology empowers the host to safely extract the module path and callable function before environment instantiation or Python interpreter invocation. \[Architecture synthesis\] A robust system distinguishes various versioning and identity concerns, which must be tracked distinctly by the host. The "Package Name" is the PEP 508 normalized identifier for the Python module used internally by Python tooling. The "Plugin ID" must be a globally unique identifier, such as a UUID or reverse-domain string, utilized by the C\# host to track installation state across versions. The "Publisher ID" operates as a cryptographic identifier representing the plugin author, verified via code signing. The "Distribution Version" is the PEP 440 compliant version of the package, while the "Contract Version" dictates the IPC protocol schema version supported by the plugin, ensuring backward or forward compatibility with the host. Finally, the "Runtime Version" specifies the required CPython compatibility baseline. \[Platform fact\] Windows historically restricts file paths to MAX\_PATH, limiting absolute paths to 260 characters. Virtual environments with deeply nested transitive dependencies frequently exceed this limit, causing critical installation and import failures. The C\# host application must prepend the \\\\?\\ prefix to absolute paths during extraction, environment creation, and execution to invoke the extended-length path API, safely bypassing the 260-character limit up to 32,767 characters10. Furthermore, the host application manifest must declare \<longPathAware\>true\</longPathAware\> to ensure all underlying Win32 API calls respect extended paths12. File locks induced by antivirus scanning or running processes must be handled by graceful retry logic and eventual reboot-pending deletion flags.

5. Interpreter and Environment Management

\[Architecture synthesis\] Selecting the correct interpreter strategy is critical for avoiding dependency contamination and ensuring system stability.

\[Proposal\] The system must utilize a Bundled CPython distribution managed exclusively by the host application. Security updates to the Python interpreter are strictly owned by the host. If a critical vulnerability is identified in CPython, the host application updates the base runtime, instantly patching all installed plugins without requiring authors to recompile or redistribute their code. Relying on the system Python introduces catastrophic environment drift and dependency collisions. \[Platform fact\] The standard python-3.x.x-embed-amd64.zip distribution provided by Microsoft and python.org disables pip and virtual environment isolation by default through its \_pth file. This makes dependency installation brittle unless modified to explicitly include import site14. To circumvent these limitations, the host should pair the embeddable distribution with uv, a high-performance Rust-based Python package manager and resolver. \[External guidance\] uv provides mathematically exact dependency resolution and creates isolated virtual environments almost instantaneously by utilizing hardlinks to a centralized cache16. Dependency locks must be represented by a uv.lock file, which is provided in the plugin submission17. The uv.lock file contains exact package versions, cryptographic hashes, and platform markers, guaranteeing reproducible installations19. For offline installations common in enterprise deployments, uv enables the pre-caching of wheels; the host can execute uv pip install \--no-index \--find-links \<local\_wheel\_dir\> to hydrate the environment without external network access20. \[Architecture synthesis\] Native wheels, compiled extensions, and heavy accelerator libraries (such as CUDA binaries) must be handled strictly as pre-compiled Windows wheels (win\_amd64). The host must parse platform tags to ensure exact ABI and architecture compatibility before initiating the installation sequence. Any reliance on the Visual C++ runtime must be declared in the manifest, allowing the host to verify the presence of the redistributable. \[Platform fact\] Virtual environments on Windows are highly susceptible to persistent file locks during execution, making clean uninstallation difficult if a subprocess fails to release file handles. What the standard ecosystem lacks is a robust garbage-collection rule. If environment drift is detected, or if a user uninstalls a plugin while a file is locked, the host must utilize the Win32 API MoveFileEx function paired with the MOVEFILE\_DELAY\_UNTIL\_REBOOT flag. This schedules the virtual environment directory for aggressive deletion by the operating system kernel upon the next system restart, preventing disk exhaustion and orphan state22.

6. Process Model and IPC

\[Architecture synthesis\] The methodology used to bridge the C\# host and the Python code dictates the reliability and security boundaries of the entire system.

\[Platform fact\] Integrating CPython directly into a .NET UI process via embedded solutions like Python.NET forces both runtimes to share a single process space. This introduces severe Global Interpreter Lock (GIL) contention, thread starvation, and application freezing if Python code executes blocking native calls24. Crucially, embedded Python is a non-existent reliability boundary; a fatal segmentation fault in a Python C-extension will instantly terminate the entire C\# host application. \[Proposal\] The Python plugin must execute as a Packaged Executable Sidecar. Named Pipes (NamedPipeServerStream) represent the optimal inter-process communication (IPC) mechanism for local Windows desktop environments. They seamlessly bypass TCP port exhaustion, firewall prompts, and localhost binding vulnerabilities inherent to HTTP loopback or gRPC, while supporting rich, asynchronous bidirectional streaming and cancellation payloads26. \[Specification\] To guarantee that sidecar Python processes terminate immediately when the C\# host closes or crashes, the host must launch the Python process within a Windows Job Object configured with the JOB\_OBJECT\_LIMIT\_KILL\_ON\_JOB\_CLOSE flag4. When the last handle to the Job Object is closed—either intentionally by the host or via unexpected host termination—the Windows kernel aggressively terminates all processes in the job hierarchy. This natively solves the descendant-process escape problem on Windows without relying on fragile heartbeat timeouts4. \[Architecture synthesis\] Standard input and output (stdin/stdout) must never be utilized for protocol framing. A stray print("hello") or logging statement from a poorly written transitive dependency will irrevocably corrupt the data stream, causing parsing failures. Therefore, IPC must occur over a dedicated Named Pipe whose address is passed via a command-line argument. Output to stdout should be redirected exclusively for human-readable diagnostic logging. \[Platform fact\] On Windows, the default Python asyncio.SelectorEventLoop does not support asynchronous operations on Named Pipes due to underlying limitations in the select API. To ensure non-blocking, high-performance IPC, the Python sidecar must explicitly initialize and configure the ProactorEventLoop, which leverages Windows I/O Completion Ports (IOCP)29. Developers must handle specific edge cases, as calling os.stat on a named pipe under the ProactorEventLoop is known to cause BrokenPipeError in specific CPython versions, necessitating careful exception handling during the startup handshake31.

7. Recommended Architecture

\[Proposal\] The definitive architecture for the host is the Job-Object Contained Named-Pipe Sidecar:

1. Package Format: A standard Wheel (.whl) accompanied by a uv.lock file and a proprietary manifest.json.
2. Interpreter Ownership: The host maintains an isolated, minimal Python distribution updated alongside the host binary.
3. Isolation Model: Each plugin receives its own uv-managed virtual environment. These environments are isolation domains for dependency resolution, but they are explicitly not security boundaries.
4. Process Model: The plugin executes in a separate, isolated child process, contained within a hierarchical Windows Job Object.
5. IPC Transport: Bidirectional Windows Named Pipes (NamedPipeServerStream) using Length-Prefixed JSON or Protocol Buffers for structured messaging.
6. Trust Assumption: Plugins are considered "low trust." They cannot crash the host but can abuse standard user-level OS resources unless further contained by AppContainers.

\[Architecture synthesis\] Embedding CPython via Python.NET is rejected due to GIL complexity, lack of crash containment, and state contamination between multiple plugins24. Container-like external services (e.g., Docker) are rejected as they introduce excessive virtualization overhead unsuitable for a native Windows desktop user experience.

8. Generic Package and Protocol Examples

\[Sample\] Proposed Directory Tree A generic package layout physically separates host-owned metadata, protocol bridging, and plugin implementation. PluginSubmission/ ├── manifest.json \# Host-owned metadata (permissions, contract version) ├── pyproject.toml \# Python metadata and standard entry points ├── uv.lock \# Deterministic hash locks for all dependencies ├── src/ │ └── generic\_plugin/ │ ├── init.py │ ├── protocol.py \# Transport, framing, and Named Pipe connection logic │ └── implementation.py\# Core business logic └── tests/ \# Conformance fixtures and integration tests \[Sample\] pyproject.toml Metadata and Entry Point

Ini, TOML \[build-system\] requires \= \["hatchling"\] build-backend \= "hatchling.build"

\[project\] name \= "generic-plugin" version \= "1.0.0" requires-python \= "\>=3.12" dependencies \= \[ "pydantic\>=2.0.0", "numpy\>=1.26.0" \]

\[project.entry-points."host.plugin.v1"\] main \= "generic\_plugin.implementation:run\_plugin"

\[Sample\] manifest.json (Host-Owned)

JSON { "plugin\_id": "com.example.generic-plugin", "publisher\_id": "CN=Example Corp, O=Example Corp", "contract\_version": "1.2.0", "required\_capabilities": \["network\_outbound", "file\_read\_workspace"\] }

\[Sample\] Protocol Module Separation (Python) The protocol module initializes the Windows-specific event loop and parses incoming length-prefixed bytes.

Python import asyncio import sys import struct import json

async def run\_protocol\_loop(pipe\_name: str, handler): \# Ensure IOCP is used on Windows for named pipes if sys.platform \== 'win32': asyncio.set\_event\_loop\_policy(asyncio.WindowsProactorEventLoopPolicy())

reader, writer \= await asyncio.open\_connection(f'\\\\\\\\.\\\\pipe\\\\{pipe\_name}')

try: while True: length\_bytes \= await reader.readexactly(4) message\_length \= struct.unpack('\>I', length\_bytes)\[0\] data \= await reader.readexactly(message\_length)

request \= json.loads(data.decode('utf-8')) response \= await handler(request)

response\_bytes \= json.dumps(response).encode('utf-8') writer.write(struct.pack('\>I', len(response\_bytes))) writer.write(response\_bytes) await writer.drain() except asyncio.IncompleteReadError: pass \# Host disconnected gracefully finally: writer.close()

9. Security and Windows Containment

\[External guidance\] Virtual environments prevent dependency collisions, but they do not act as security sandboxes32. Malicious code inside a venv executes with the exact permissions of the spawning user, possessing full access to user documents, network interfaces, and process memory. Source distributions (.tar.gz) introduce massive security risks through arbitrary code execution hooks triggered by setup.py during installation. The system must completely prohibit source distributions in production, permitting only pre-built wheels with cryptographic hashes verified strictly against the uv.lock file34. Software Bill of Materials (SBOM) generation, vulnerability scanning, and license reviews must occur at plugin submission to quarantine code susceptible to package confusion or typosquatting attacks before distribution. \[Architecture synthesis\] To genuinely sandbox Python execution on a Windows desktop, the child process must be launched inside a Less Privileged AppContainer (LPAC). LPAC enforces a low-integrity level, completely stripping the process of access to the file system, network, and registry unless explicitly granted via Capability Security Identifiers (SIDs)5. \[Platform fact\] Running CPython inside an AppContainer introduces substantial architectural complexities. CPython and native extensions heavily utilize LoadLibrary to load .pyd and .dll files. In an AppContainer, LoadLibrary will fail with Error 4250 (ERROR\_APPCONTAINER\_REQUIRED) if the target DLL lacks proper ACLs granting the ALL APPLICATION PACKAGES group or the specific LPAC SID read and execute access37. Additionally, CPython expects read access to global variables in the registry and generalized system pathing39. \[Proposal\] The Windows containment plan dictates the following applied controls:

1. Feasible Control: Apply AppContainer via PROC\_THREAD\_ATTRIBUTE\_SECURITY\_CAPABILITIES during CreateProcessW5.
2. Filesystem ACLs: The host must programmatically modify the Access Control List (ACL) of the venv and Python interpreter directories to grant the AppContainer SID explicit RX (Read/Execute) access. This ensures LoadLibrary succeeds on native extensions41.
3. Network Controls: Strip all outbound network access by default, omitting the internetClient capability32.
4. Child-Process Limits: The Job Object must deny the ability for the Python process to break away and spawn independent child processes.
5. Secrets Management: Secrets must never be passed via CLI arguments (which are visible in WMI and Task Manager) or Environment Variables (which leak into descendant processes). They must be securely transmitted post-launch via the Named Pipe protocol.

10. Lifecycle, Failure Handling, and Observability

\[Architecture synthesis\] The host application oversees an explicitly defined state machine for each plugin, ensuring predictability and recovery. The fundamental lifecycle encompasses:

• Validate: Parse manifest.json and Wheel metadata securely without execution.
• Install: Utilize uv pip install \--no-index using cached or submitted wheels into a unique, hashed venv.
• Configure: Establish environment variables and generate the named pipe.
• Start: Launch process via CreateProcessW within a Job Object, passing the Named Pipe UUID.
• Health: Monitor via periodic application-level ping/pong heartbeats over the IPC pipe.
• Suspend: Halt the underlying process threads via Windows API (if required to free CPU).
• Stop: Transmit a graceful shutdown envelope. If the process ignores it for \>5000ms, force termination.
• Update: Install the new version side-by-side. Perform atomic promotion by updating a symbolic link or configuration pointer.
• Uninstall: Delete environment immediately. Fallback to MOVEFILE\_DELAY\_UNTIL\_REBOOT if locked23.

\[Proposal\] Install and Launch Pseudocode Algorithm: FUNCTION InstallPlugin(ArtifactPath) ValidateSignature(ArtifactPath) ExtractManifest(ArtifactPath) ExtractWheel(ArtifactPath)

TargetVenv \= Hash(PluginID \+ Version) IF Exists(TargetVenv) RETURN Error

Execute uv venv Create TargetVenv Execute uv pip install \--no-index \--exact TargetVenv/Wheel

GrantAppContainerACLs(TargetVenv) UpdateCatalog(PluginID, TargetVenv)

END FUNCTION FUNCTION LaunchPlugin(PluginID) PipeName \= GenerateUUID() CreateNamedPipeServer(PipeName)

JobHandle \= CreateJobObject(JOB\_OBJECT\_LIMIT\_KILL\_ON\_JOB\_CLOSE)

ProcessHandle \= CreateProcess( Executable \= "python.exe", Arguments \= "-m generic\_plugin \--pipe " \+ PipeName, AppContainerToken \= GenerateLPACToken() )

AssignProcessToJobObject(JobHandle, ProcessHandle)

WaitConnection(PipeName, Timeout=5000ms) SendHandshake(PipeName, Capabilities)

END FUNCTION \[Architecture synthesis\] Process Protocol Considerations: The protocol must define strict framing, consisting of a 4-byte big-endian integer representing payload length, followed by the payload. Payloads should include a Correlation ID and Request ID to map asynchronous responses to origin requests. Sequence numbers prevent replay issues. Streaming chunks must define a terminal result flag to close the stream. Error envelopes must separate protocol-level framing errors from application-level exceptions. \[Proposal\] Failure-Mode Catalog:

• Broken Wheel / Unsupported Tag: Rejected at validation phase by uv.
• Dependency Conflict: Mitigated completely by strict per-plugin virtual environments.
• Native-Load Failure: Caught during initial handshake; often caused by missing VC++ runtimes or incorrect AppContainer ACLs on .pyd files.
• Import Side Effect: Hangs during initialization trigger a startup timeout (e.g., 5000ms), resulting in a forced kill.
• Stdout Contamination: Ignored, as IPC relies exclusively on the Named Pipe.
• Crash Loop: Detected by host if a plugin restarts more than 3 times in 60 seconds; plugin is quarantined.
• Orphan Child / Shutdown Refusal: Prevented completely by the Windows Job Object.
• Memory Growth: Host monitors Job Object memory statistics. If it exceeds manifest limits, a forced termination is issued.

\[Architecture synthesis\] Asynchronous Python plugins interoperate safely with the host because the C\# async/await state machine and the Python asyncio event loop are fully decoupled by the Named Pipe boundary. Logs and crash evidence remain useful because stdout and stderr are piped to rolling diagnostic text files separated from the structured IPC channel, preventing credentials or private model output from polluting telemetry unless explicitly requested.

11. SDK and Developer Experience

\[Architecture synthesis\] To minimize developer burden and enforce packaging correctness, the host organization must provide a comprehensive Python plugin SDK. \[Proposal\] The SDK must provide:

1. Typed Protocol Models: Pydantic schemas validating all inbound and outbound JSON RPC structures to enforce strict contract testing18.
2. Decorators/Entry-Point Helpers: Standardized wrappers (e.g., @plugin.handle\_request) that abstract the initialization of the ProactorEventLoop, connect to the named pipe, and route requests safely to business logic.
3. CLI Validator: A command-line tool that statically analyzes the plugin's pyproject.toml and manifest, ensuring compatibility, valid environment markers, and the absence of prohibited dependencies before submission.
4. Test Fakes: Mock implementations of the C\# host that allow developers to test plugin logic natively in Python without launching the heavy host application.
5. Packaging Template: A GitHub template repository pre-configured with Hatchling, uv, and GitHub Actions to automate wheel generation and lockfile updates.

\[Specification\] Type hints, JSON Schema generation, and Pydantic validation form a tripartite defense. The SDK generates JSON Schemas from Pydantic models, which the C\# host consumes to generate equivalent C\# records. This enforces contract tests across the language barrier. Compatibility combinations must be tested across Python versions (e.g., 3.12, 3.13), Windows OS builds (Windows 10 vs 11 AppContainer behavior), architecture (win\_amd64), and protocol versions to guarantee stability.

12. Automated-Test Strategy

\[Proposal\] The host architecture requires rigorous, automated testing across runtime boundaries:

• Package-Inspection Tests: Supply maliciously crafted wheels with incorrect tags or missing RECORD files to ensure the resolver cleanly rejects them.
• Lifecycle & Protocol Tests: Verify environments are created cleanly and destroyed successfully, tracking registry handles to detect resource leaks. Ensure malformed IPC messages trigger error envelopes, not crashes.
• Containment & Chaos Tests: Supply intentionally bad fixture plugins that attempt to write to C:\\Windows, allocate 10GB of memory, fork child processes (descendant escape), or execute infinite loops (while True: pass). Confirm the Job Object and AppContainer successfully block or terminate the plugin, producing expected rejection reasons5.
• Cancellation Tests: Transmit a long-running request, then send a cancellation token via IPC. Ensure the Python task raises an asyncio.CancelledError and cleans up resources without hanging the pipe.
• Crash Containment: Trigger a C-level Segfault in a mock native module using ctypes. Ensure the Named Pipe connection drops gracefully, the host logs a warning, and no host UI freezing occurs.

13. Open Implementation Questions

\[Unknown\] Several operational nuances require further prototyping and empirical validation:

1. Native Extension Compatibility in LPAC: Which specific data science or numeric libraries (e.g., PyTorch, NumPy) invoke OS routines that are hard-blocked by AppContainer virtualized registries, and what are the specific ACL propagation requirements necessary to unblock them without compromising the sandbox?
2. Anti-Virus Heuristics: Will dynamic creation of executable Python sidecars and named pipes trigger generic Endpoint Detection and Response (EDR) blocking mechanisms on heavily restricted enterprise networks?
3. Environment Deduplication: If multiple plugins rely on identical heavy dependencies (e.g., CUDA DLLs), what is the optimal caching layout to prevent disk bloat while retaining strict per-plugin isolation and uv hardlinking efficiency?

14. Limitations

\[Architecture synthesis\] This architecture presents specific trade-offs:

1. Startup Latency: Spawning a new Python process and initializing the asyncio loop incurs a \~100-300ms penalty compared to direct embedded function calls. This restricts the use case to asynchronous, macro-level operations rather than high-frequency, frame-by-frame UI rendering callbacks.
2. Memory Overhead: Each plugin claims its own CPython memory footprint (\~15-30MB baseline) and loaded module duplicates. Ten active plugins require ten independent memory spaces, limiting scalability on low-end hardware.
3. Serialization Costs: Large data structures (e.g., massive DataFrames, Tensors) must be serialized over the Named Pipe. While Shared Memory (multiprocessing.shared\_memory) could mitigate this, it breaks AppContainer boundaries and significantly complicates cross-process synchronization.

Works cited

1. pyproject.toml specification \- Python Packaging User Guide, https://packaging.python.org/en/latest/specifications/pyproject-toml/
2. Recording installed projects \- Python Packaging User Guide, https://packaging.python.org/specifications/recording-installed-packages/
3. Day 38 — What's inside a Python wheel? \- Vinayak Mehta, https://vinayak.io/2020/10/04/day-38-whats-inside-a-python-wheel/
4. Killing all child processes when the parent exits (Job Object) \- Meziantou's blog, https://www.meziantou.net/killing-all-child-processes-when-the-parent-exits-job-object.htm
5. Windows renderer sandbox (Job objects \+ AppContainer \+ restricted token) \- GitHub, https://github.com/wilsonzlin/fastrender/blob/main/docs/windows\_sandbox.md
6. Launch an AppContainer \- Win32 apps \- Microsoft Learn, https://learn.microsoft.com/en-us/windows/win32/secauthz/implementing-an-appcontainer
7. The pyproject.toml file | Documentation | Poetry \- Python dependency management and packaging made easy, https://python-poetry.org/docs/pyproject/
8. Getting Entry Points from PyPI \- PaulTraylor.net, https://paultraylor.net/blog/2026/getting-entry-points-from-pypi/
9. How do I list the files inside a python wheel? \- Stack Overflow, https://stackoverflow.com/questions/32923952/how-do-i-list-the-files-inside-a-python-wheel
10. Why does the 260 character path length limit exist in Windows? \- Stack Overflow, https://stackoverflow.com/questions/1880321/why-does-the-260-character-path-length-limit-exist-in-windows
11. Maximum Path Length Limitation \- Win32 apps \- Microsoft Learn, https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation
12. Remove the Max Path Length Limit (260-Characters) on Windows, https://woshub.com/max-path-length-limit-windows/
13. Path length limit on Windows \- The R Blog, https://blog.r-project.org/2023/03/07/path-length-limit-on-windows/
14. Using pip with Windows Python Embeddable \- DEV Community, https://dev.to/vast-cow/using-pip-with-windows-python-embeddable-3ali
15. pip with embedded python \- Stack Overflow, https://stackoverflow.com/questions/42666121/pip-with-embedded-python
16. A Modern Python Workflow with Astral uv \- Hypertext Dispatches, https://tenthirtyam.org/dispatches/2026/05/21/a-modern-python-workflow-with-astral-uv/
17. Using uv: A Modern Python Workflow | Tyler Crosse, https://tylercrosse.com/ideas/2025/uv/
18. UV for Python Project and Version Management : r/learnpython \- Reddit, https://www.reddit.com/r/learnpython/comments/1jbo88t/uv\_for\_python\_project\_and\_version\_management/
19. Structure and files | uv \- Astral Docs, https://docs.astral.sh/uv/concepts/projects/layout/
20. Transfer offline PyTorch wheel (downloaded using UV by Unsloth Studio installer) to oter computers, as an offline package installer. How to? · Issue \#5833 \- GitHub, https://github.com/unslothai/unsloth/issues/5833
21. uv-pip-offline-download | Skills Mar... \- LobeHub, https://lobehub.com/skills/dstoc-cladding-uv-pip-offline-download
22. How can I delay file deletion until next reboot from my program? \- Stack Overflow, https://stackoverflow.com/questions/5490658/how-can-i-delay-file-deletion-until-next-reboot-from-my-program
23. How does Windows remove locked files in the next reboot when you uninstall a program?, https://stackoverflow.com/questions/21641006/how-does-windows-remove-locked-files-in-the-next-reboot-when-you-uninstall-a-pro
24. Rhino BETA Feature: Python 3.13 \- Scripting \- McNeel Forum, https://discourse.mcneel.com/t/rhino-beta-feature-python-3-13/205209
25. Python .NET, multithreading and the windows event loop \- Stack Overflow, https://stackoverflow.com/questions/45753171/python-net-multithreading-and-the-windows-event-loop
26. NamedPipeServerStream Class (System.IO.Pipes) | Microsoft Learn, https://learn.microsoft.com/en-us/dotnet/api/system.io.pipes.namedpipeserverstream?view=net-10.0
27. Harnessing the power of Named Pipes \- CyberCX, https://cybercx.com.au/blog/harnessing-the-power-of-named-pipes/
28. Windows API Job Objects: Don't pass on to grandchildren \- Stack Overflow, https://stackoverflow.com/questions/33424492/windows-api-job-objects-dont-pass-on-to-grandchildren
29. 18.5.2. Event loops — documentação Python 3.6.15, https://docs.python.org/pt-br/3.6/library/asyncio-eventloops.html
30. What are SelectorEventLoop and ProactorEventLoop in python asyncio \- Stack Overflow, https://stackoverflow.com/questions/67964463/what-are-selectoreventloop-and-proactoreventloop-in-python-asyncio
31. Calling os.stat() on a named pipe used by asyncio.ProactorEventLoop.start\_serving\_pipe() will raise OSError · Issue \#100573 · python/cpython \- GitHub, https://github.com/python/cpython/issues/100573
32. AppContainers for Windows 8: What Are They and How Can You Create Them? | by Apriorit, https://medium.com/apriorit/appcontainers-for-windows-8-what-are-they-and-how-can-you-create-them-e5970a28eea4
33. Python embeddable zip \- Stack Overflow, https://stackoverflow.com/questions/37633550/python-embeddable-zip
34. Building Python Wheel without internet connection \- Stack Overflow, https://stackoverflow.com/questions/79866286/building-python-wheel-without-internet-connection
35. Caching | uv \- Astral Docs, https://docs.astral.sh/uv/concepts/cache/
36. Fun with AppContainers \- Pavel Yosifovich, https://scorpiosoftware.net/2019/01/15/fun-with-appcontainers/
37. LoadLibrary fails with error 4250: This operation is only valid in the context of an app container \- Stack Overflow, https://stackoverflow.com/questions/47765723/loadlibrary-fails-with-error-4250-this-operation-is-only-valid-in-the-context-o
38. How do I fix file permissions for C:\\Program Files\\WindowsApps? I changed the permissions so I could change something for an app. \- Microsoft Learn, https://learn.microsoft.com/en-us/answers/questions/4269131/how-do-i-fix-file-permissions-for-c-program-filesw
39. File access permissions \- Windows apps \- Microsoft Learn, https://learn.microsoft.com/en-us/windows/apps/develop/files/file-access-permissions
40. Using MSIX packaging for Visual Studio, App doesn't write in registry \- Stack Overflow, https://stackoverflow.com/questions/79494603/using-msix-packaging-for-visual-studio-app-doesnt-write-in-registry
41. Safely View WindowsApps Folders and Manage App Installations \- Windows Forum, https://windowsforum.com/threads/safely-view-windowsapps-folders-and-manage-app-installations.389218/
42. Application Isolation \- Windows 11 Security Book \- Microsoft Learn, https://learn.microsoft.com/en-us/windows/security/book/application-security-application-isolation