Skip to main content

Python SDK for NNRP protocol primitives and adapters

Project description

NNRP - Neural Network Runtime Protocol

CI Python Docs Apache-2.0

nnrp-py

Python SDK scaffold for NNRP.

This repository keeps a neutral protocol-level name because it is intended to host shared wire-format code plus server- and client-facing helpers. Host-application integration stays outside this repository so the package layout can serve Python clients, servers, script hosts, or tooling without binding the SDK to any single backend checkout.

NNRP should be read as a lightweight real-time AI application protocol, not as a neural-rendering-only transport. The current runtime integration happens to start from tensor/tile-oriented super-resolution flows, but the current NNRP/1 wire already covers token streaming, multimodal payload delivery, structured events, tool deltas, transport probing, and migration-oriented session control.

Contributors

Contributors

The avatar wall above updates automatically from the repository contributor list once this repository is published at the matching GitHub location.

GitHub README rendering does not support per-avatar dynamic tooltips for an auto-generated contributor wall, so use the linked contributors graph if you want individual profile pages and account IDs.

Scope

This repository contains protocol-focused code only:

  1. Rust-backed client connection/session helpers for host integrations.
  2. Common wire constants, enums, and packet codecs for protocol fixtures and diagnostics.
  3. Shared client/server protocol-side models.
  4. Transport adapters, replay helpers, and smoke tooling for SDK bring-up.

It does not contain neural rendering runtime business logic.

Layout

  • src/nnrp/core/: shared protocol primitives and wire helpers.
  • src/nnrp/cache.py: Preview3 cache identity, lease, version, and invalidation result wrappers.
  • src/nnrp/native.py: FFI loader, ABI/protocol probes, native handle wrappers, and runtime facade.
  • src/nnrp/native_artifacts/: packaged nnrp-rs native libraries, arranged by platform tag.
  • src/nnrp/schema.py: Preview3 schema/profile descriptor views and first-round standard registry constants.
  • src/nnrp/client/: client-facing native connection/session helpers plus transport smoke helpers.
  • src/nnrp/server/: server-facing helpers and types.
  • src/nnrp/adapters/: transport or host integration adapters.
  • src/nnrp/tools/: adapter conformance, benchmark, replay, diagnostics, and smoke helpers.
  • tests/: protocol-level, native facade, conformance, and smoke tests.

The top-level nnrp package keeps top-level re-exports for common imports, while new code should prefer the explicit submodules.

Native Host API

Host integrations should start with the Rust-backed client helpers in nnrp.client. The Python layer owns a small, Pythonic surface, while protocol-critical session, operation, polling, and status behavior is delegated to the packaged nnrp-rs native runtime.

from nnrp.client import (
	NativeClientConnectionOptions,
	NativeClientSessionOpenOptions,
	connect_native_client_connection,
)

with connect_native_client_connection(
	options=NativeClientConnectionOptions(connection_id=7),
	require_native=True,
) as connection:
	session = connection.open_session(
		NativeClientSessionOpenOptions(
			requested_session_id=42,
			profile_id=1,
			schema_id=1,
			schema_version=1,
		)
	)
	result = connection.submit_and_poll_result(
		session,
		operation_id=1001,
		frame_id=1,
		payload=b"tensor-or-typed-payload-bytes",
		max_events=8,
	)
	print(result.state, result.payload)

The native helpers provide:

  1. connect_native_client_connection() for one Rust-backed connection that can own multiple sessions.
  2. NativeClientConnection.open_session() for explicit session creation.
  3. NativeClientConnection.submit_and_poll_result() for a host-friendly submit/result roundtrip over native session operations.
  4. NativeRuntimeSession.submit_operation() and NativeClientConnection.operation_scope() for operation handles, parent/group metadata, and cancellation on exceptional exits.
  5. NativeClientConnection.poll_result(), native async polling helpers, and callback dispatch helpers for result/event delivery.
  6. NativeClientConnection.cancel_frame() / NativeClientConnection.cancel_operation() / NativeClientConnection.send_control() for host control paths.

By default the native loader searches nnrp/native_artifacts/<os>-<arch>/ inside the installed package. Set NNRP_NATIVE_ARTIFACT_ROOT when testing an external artifact tree. Pass require_native=True in host code that must fail fast instead of falling back to SDK-local fixtures.

The native binding layer has two paths. The default NNRP_NATIVE_BINDING_MODE=auto tries a packaged cffi API fast path for compact submit/result operations and falls back to the zero-compile ctypes ABI path when that module is unavailable or cannot preserve the requested payload semantics. Set NNRP_NATIVE_BINDING_MODE=ctypes for compiler-free diagnostics, or NNRP_NATIVE_BINDING_MODE=cffi_api when a benchmark or deployment should fail fast unless the cffi API module is present.

Polled native events and results expose Python-owned bytes payload snapshots. The current Python API does not expose borrowed result buffers, so a result object remains stable even if the native runtime reuses its poll buffer after the call returns.

Cache leases and schema validation follow the same host/runtime split. Python code passes stable identifiers, descriptors, and payload views into the native runtime; lease policy, schema matching, and diagnostics remain owned by Rust:

from nnrp import (
	CacheObjectIdentity,
	cache_query,
	cache_touch,
	token_delta_payload_descriptor,
	token_delta_schema_descriptor,
)
from nnrp.client import NativeClientSessionOpenOptions, connect_native_client_connection

with connect_native_client_connection(require_native=True) as connection:
	session = connection.open_session(NativeClientSessionOpenOptions(requested_session_id=42))

	cache = session.cache_backend(now_ms=10_000, ttl_ms=30_000)
	identity = CacheObjectIdentity(namespace=1, object_kind=1, key_hi=0, key_lo=7)
	lease = cache_query(cache, identity)
	if lease.succeeded:
		cache_touch(cache, identity, ttl_ms=60_000)

	registry = connection.schema_registry()
	registry.install(token_delta_schema_descriptor())
	registry.validate_typed_payload_binding(
		token_delta_payload_descriptor(offset=0, length=128)
	)

profile_id = 0 means unspecified. It must not be treated as an implicit tensor profile. Tensor and token payloads are peer standard profiles, while structured-event, tool-delta, and workflow-state remain payload families routed through schema/profile bindings before any profile-private body decoding happens.

NativeRuntimeResult.state reports the host-visible operation lifecycle as completed, partial, degraded, stale_reuse, cancelled, or failed. NativeRuntimeResult.diagnostic preserves native status, error family, protocol detail, and related connection/session/operation/frame ids; use NativeStructuredDiagnostic.to_report() when emitting adapter or CI diagnostics instead of flattening native failures into strings.

Public Wire API

The public wire surface remains available for protocol fixtures, diagnostics, and tooling. It should not be treated as the primary host runtime path when native artifacts are available. The legacy connect_client_session() and connect_client_session_with_probe() helpers remain available from nnrp.client.transport only for packet transport smoke tests and adapter bring-up. Production host integrations should use the Rust-backed native connection/session helpers from nnrp.client.

Schema And Profile Constants

Preview3 schema/profile helpers expose stable descriptor views without decoding profile-private payload bodies:

from nnrp import StandardProfile, StreamSemantics, token_delta_payload_descriptor

descriptor = token_delta_payload_descriptor(offset=0, length=128)
assert descriptor.profile_id is StandardProfile.TOKEN
assert descriptor.stream_semantics is StreamSemantics.APPEND

StandardProfile.UNSPECIFIED stays distinct from StandardProfile.TENSOR; structured-event and tool-delta remain payload families interpreted through schema/profile bindings rather than standalone standard profiles.

CacheObjectIdentity, CacheLeaseDescriptor, and SchemaRegistryCatalog are host-side value wrappers for native/runtime results and diagnostics. Cache query/touch/prefetch/release helpers delegate to a backend object and do not accept local lease policy callbacks or profile body decoders; those decisions remain owned by Rust and the conformance baseline.

Native connections also expose async iterators and callback dispatch helpers for structured_event, tool_delta, and workflow-state payload families. These helpers wrap result/control events from the native pump and preserve Python-owned payload snapshots; profile-private body decoding still belongs to schema/profile handlers rather than the iterator or callback itself.

The wire surface is centered on two modules:

  1. nnrp.core: fixed-width header/message codecs, packet builders, tensor section helpers, and packet/body parsing.
  2. nnrp.tools: replay helpers, smoke helpers, adapter conformance, benchmark, and wire-size summary/comparison utilities.

Use nnrp.core when you already have protocol-shaped inputs and want explicit control over header fields, tile ids, section payloads, and packet assembly.

from nnrp.core import (
	HeaderFlags,
	InputProfile,
	TensorSectionData,
	TensorDType,
	TileIndexMode,
	build_frame_submit_packet,
	unpack_tensor_body,
)

packet = build_frame_submit_packet(
	session_id=7,
	frame_id=42,
	src_width=640,
	src_height=360,
	tile_width=32,
	tile_height=32,
	tile_ids=(5, 6),
	sections=(
		TensorSectionData(
			role_id=1,
			default_codec_id=0,
			dtype_id=TensorDType.FP16,
			tile_payloads=(b"aa", b""),
		),
	),
	camera_block=b"cam",
	input_profile=InputProfile.DENSE_LUMA_FRAME,
	tile_index_mode=TileIndexMode.DENSE_RANGE,
	flags=HeaderFlags.ACK_REQUIRED,
)

encoded = packet.pack()
decoded_body = unpack_tensor_body(
	packet.body[3:],
	tile_index_bytes=0,
	section_count=1,
	tile_count=2,
)

The builder/parser layer currently guarantees:

  1. Header length and packet length consistency.
  2. Tile count / section count consistency.
  3. Strictly increasing role_id ordering across tensor sections.
  4. Fixed-stride, codec-table, and tile-length-table self-consistency checks.
  5. RESULT_PUSH tensor coverage and result-flag consistency validation.

Replay And Diagnostics Workflow

Use nnrp.tools.replay when the source object still looks like host-side runtime data and you need protocol-shaped fixture bytes, diagnostics, or wire-size comparisons.

from nnrp.tools import (
	compare_frame_features_wire_size,
	frame_features_to_wire_bytes,
	frame_features_to_wire_summary,
	render_wire_summary,
	render_wire_size_comparison,
)

wire_bytes = frame_features_to_wire_bytes(frame_features)
summary = frame_features_to_wire_summary(frame_features)
comparison = compare_frame_features_wire_size(
	frame_features,
	reference_payload=protobuf_bytes,
	reference_label="protobuf",
)

print(len(wire_bytes))
print(render_wire_summary(summary))
print(render_wire_size_comparison(comparison))

The replay helpers currently provide:

  1. frame_features_to_packet / frame_features_to_wire_bytes for submit fixture generation.
  2. enhance_result_to_packet / enhance_result_to_wire_bytes for result fixture generation.
  3. frame_features_to_wire_summary / enhance_result_to_wire_summary for stable packet summaries.
  4. compare_frame_features_wire_size / compare_enhance_result_wire_size for wire-vs-reference payload size comparison without taking a protobuf dependency.

reference_payload is intentionally just raw bytes. The protocol library does not depend on protobuf schemas; host applications remain responsible for producing the reference payload they want to compare against NNRP wire bytes.

Workflow Notes

  1. Prefer nnrp.client.connect_native_client_connection() for host runtime integration.
  2. Prefer nnrp.core when writing protocol-native tests or SDK integration code.
  3. Prefer nnrp.tools when building replay fixtures or generating stable regression summaries.
  4. For transport bring-up, use nnrp.tools.smoke, nnrp-quic-smoke, or the tooling-only packet session helpers rather than reimplementing ad hoc control packets.

Current Session Model

The canonical host shape is a long-lived native connection with one or more explicit sessions. Hosts submit operations through a session and consume results through the native result/event pump.

from nnrp.client import NativeClientSessionOpenOptions, connect_native_client_connection

with connect_native_client_connection(require_native=True) as connection:
	interactive = connection.open_session(
		NativeClientSessionOpenOptions(requested_session_id=10, profile_id=1)
	)
	batch = connection.open_session(
		NativeClientSessionOpenOptions(requested_session_id=11, profile_id=2)
	)

	interactive_op = interactive.submit_operation(
		operation_id=2001,
		frame_id=1,
		payload=b"interactive-frame",
	)
	batch_op = batch.submit_operation(
		operation_id=3001,
		frame_id=1,
		payload=b"batch-frame",
	)

	interactive_result = connection.poll_result(interactive, interactive_op, max_events=16)
	batch_result = connection.poll_result(batch, batch_op, max_events=16)
	print(interactive_result.state, batch_result.state)

Hosts should keep submission and result consumption decoupled so multiple operations can remain in flight while result, cancellation, control, and diagnostic events continue to arrive on the same connection. The connection context closes owned sessions on exit.

Conformance

The shared nnrp-conformance suite owns protocol baselines, parameterized wire cases, adapter execution plans, and result validation. The Python SDK participates by declaring capabilities and running python -m nnrp.tools.adapter_conformance --plan <path> --output <path> against suite-selected cases.

SDK tests should exercise real Python APIs and native bridge behavior through adapter plans, benchmark plans, smoke tests, and focused unit tests rather than generating separate protocol vector manifests.

Current Wire Additions

The current NNRP/1 wire keeps the 40-byte common header stable and changes the protocol surface in four main ways.

  1. FRAME_SUBMIT and RESULT_PUSH gain aligned fixed metadata so submit mode, budget policy, dependency tracking, payload-kind bitmaps, payload-frame counts, and result classes become explicit wire fields instead of host-side conventions.
  2. The current body is no longer an implicit tensor-only blob. It starts with BodyRegionPrelude and then carries deterministic ordered regions for inline objects, object references, typed-payload descriptors, typed-payload frames, extension descriptors, and extension payloads.
  3. Submit/result flows are no longer tensor-only. The current wire can carry tensor, token_chunk, audio_chunk, video_chunk, structured_event, tool_delta, and opaque_bytes payload kinds in one packet, while still preserving tensor-specific coverage rules only when tensor payloads are actually present.
  4. The current wire adds runtime control messages and session mechanics for FLOW_UPDATE, RESULT_HINT, TRANSPORT_PROBE, TRANSPORT_PROBE_ACK, SESSION_MIGRATE, and SESSION_MIGRATE_ACK.

In practice, the current wire is the general-purpose session model for mixed object references, mixed payload kinds, explicit degradation semantics, and long-lived asynchronous multi-frame sessions.

Object Reference Workflow

The current wire treats cache-backed object references as first-class protocol inputs rather than ad hoc host shortcuts.

The expected cache lifecycle is:

  1. Advertise the supported cache object kinds during handshake through cache_object_bitmap and related fixed metadata.
  2. Put stable objects into the session cache through CACHE_PUT / CACHE_ACK before the hot path starts referencing them.
  3. Reference stable objects from FRAME_SUBMIT or RESULT_PUSH through object-reference regions instead of resending the same bytes inline every frame.
  4. Invalidate session-, namespace-, object-kind-, or object-key-scoped entries through CACHE_INVALIDATE when the producer knows the references should no longer be reused.
  5. Treat cache misses and unsupported object kinds as explicit protocol errors; do not silently fall back to a guessed inline path.

Typical submit-side mixed mode looks like this:

  1. Keep rapidly changing tensor section data inline.
  2. Move low-frequency camera blocks, tile-index templates, or tensor section tables into cache objects.
  3. Set submit_mode to reference or mixed and align object_ref_mask with the standard reference slots present in the body.

This lets hosts reduce repeated hot-path bytes without hiding cache policy inside runtime-private handles.

Current Result Semantics

Host repositories should treat current result classes as display policy signals, not just transport decoration.

  1. complete means the result fully covers the requested tensor scope or fully satisfies the non-tensor payload set carried by the packet.
  2. partial means the result is still displayable or consumable, but only covers part of the requested output. Tensor results must make that visible through covered_tile_count and dropped_tile_count.
  3. stale_reuse means the result intentionally reuses older frame/object content. Hosts should surface the reuse relationship instead of treating it as a fresh complete inference.
  4. degraded means the service intentionally lowered fidelity or fell back because of budget, congestion, or resource pressure. Hosts should not collapse this into transport failure.
  5. RESULT_DROP remains the non-displayable terminal path. A degraded or stale result is still a positive result path and should usually stay on the render or consumer timeline.

For host integrations, the important rule is to preserve the distinction between “nothing usable arrived” and “a usable but lower-quality result arrived”. The current wire keeps backpressure, budget enforcement, stale reuse, and graceful degradation explicit instead of burying them in app-specific heuristics.

Typed Payload And Extension Frames

Typed payloads let one packet carry non-tensor application content without pretending everything is a tensor section.

Current payload helpers in nnrp.core cover:

  1. build_token_chunk_frame for token streaming and incremental text generation.
  2. build_audio_chunk_frame and build_video_chunk_frame for multimodal streaming payloads.
  3. build_structured_event_frame for structured dialogue or agent-side event records.
  4. build_tool_delta_frame for tool-call progress and coding-agent style delta streams.
  5. build_frame_submit_typed_payload_packet, build_result_push_typed_payload_packet, and mixed builders when tensor plus non-tensor payloads must travel together.
from nnrp.core import (
	build_frame_submit_typed_payload_packet,
	build_structured_event_frame,
	build_token_chunk_frame,
)

packet = build_frame_submit_typed_payload_packet(
	session_id=7,
	frame_id=101,
	frames=(
		build_token_chunk_frame(b"tok", profile_id=1),
		build_structured_event_frame(b'{"phase":"thinking"}', profile_id=2),
	),
)

Extension frames remain the escape hatch for standardized or future protocol-side metadata that should not be forced into fixed metadata fields. Unknown non-critical extension frames must be skippable, while unknown critical extension frames must remain hard failures so SDKs do not silently misinterpret application semantics.

Transport Helper Boundary

The current transport-facing boundary is intentionally narrow.

nnrp-py keeps the helpers that remain runtime-agnostic across different hosts and SDKs. These helpers are intentionally positioned as tooling, diagnostics, or cross-SDK bring-up surfaces, not as the default host runtime API:

  1. QUIC connection/listener primitives in nnrp.adapters.
  2. TLS / ALPN configuration helpers such as create_quic_client_configuration and create_quic_server_configuration.
  3. Cross-SDK bring-up helpers in nnrp.tools.smoke.
  4. Protocol-native packet builders, parsers, replay helpers, and wire-size diagnostics.

Host applications keep everything that depends on runtime policy, business objects, or deployment wiring:

  1. Session lifecycle policy above the protocol primitives.
  2. Runtime-specific request/response models and object adaptation.
  3. Port sharing, service bootstrap, and multi-protocol listener orchestration.
  4. Production health checks, telemetry pipelines, and application-specific retry policy.

In practice this means nnrp-py owns reusable protocol machinery, while host/application repositories own the code that binds those primitives to concrete service policy and deployment wiring.

Development

python -m pip install -e .[dev]
python -m pytest

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

nnrp_py-1.0.0rc3.tar.gz (20.9 MB view details)

Uploaded Source

Built Distributions

If you're not sure about the file name format, learn more about wheel file names.

nnrp_py-1.0.0rc3-py3-none-win_arm64.whl (231.4 kB view details)

Uploaded Python 3Windows ARM64

nnrp_py-1.0.0rc3-py3-none-win_amd64.whl (239.5 kB view details)

Uploaded Python 3Windows x86-64

nnrp_py-1.0.0rc3-py3-none-win32.whl (234.9 kB view details)

Uploaded Python 3Windows x86

nnrp_py-1.0.0rc3-py3-none-manylinux_2_28_i686.whl (375.2 kB view details)

Uploaded Python 3manylinux: glibc 2.28+ i686

nnrp_py-1.0.0rc3-py3-none-manylinux_2_28_armv7l.whl (360.4 kB view details)

Uploaded Python 3manylinux: glibc 2.28+ ARMv7l

nnrp_py-1.0.0rc3-py3-none-manylinux_2_28_aarch64.whl (347.7 kB view details)

Uploaded Python 3manylinux: glibc 2.28+ ARM64

nnrp_py-1.0.0rc3-py3-none-macosx_11_0_x86_64.whl (334.3 kB view details)

Uploaded Python 3macOS 11.0+ x86-64

nnrp_py-1.0.0rc3-py3-none-macosx_11_0_arm64.whl (326.4 kB view details)

Uploaded Python 3macOS 11.0+ ARM64

nnrp_py-1.0.0rc3-py3-none-ios_13_0_x86_64_iphonesimulator.whl (6.0 MB view details)

Uploaded Python 3iOS 13.0+ x86-64 Simulator

nnrp_py-1.0.0rc3-py3-none-ios_13_0_arm64_iphonesimulator.whl (5.9 MB view details)

Uploaded Python 3iOS 13.0+ ARM64 Simulator

nnrp_py-1.0.0rc3-py3-none-ios_13_0_arm64_iphoneos.whl (5.9 MB view details)

Uploaded Python 3iOS 13.0+ ARM64 Device

nnrp_py-1.0.0rc3-py3-none-android_24_x86_64.whl (367.8 kB view details)

Uploaded Android API level 24+ x86-64Python 3

nnrp_py-1.0.0rc3-py3-none-android_24_x86.whl (386.8 kB view details)

Uploaded Android API level 24+ x86Python 3

nnrp_py-1.0.0rc3-py3-none-android_24_armeabi_v7a.whl (341.0 kB view details)

Uploaded Android API level 24+ ARM EABI v7aPython 3

nnrp_py-1.0.0rc3-py3-none-android_24_arm64_v8a.whl (366.0 kB view details)

Uploaded Android API level 24+ ARM64 v8aPython 3

nnrp_py-1.0.0rc3-cp311-cp311-manylinux_2_28_x86_64.whl (368.6 kB view details)

Uploaded CPython 3.11manylinux: glibc 2.28+ x86-64

File details

Details for the file nnrp_py-1.0.0rc3.tar.gz.

File metadata

  • Download URL: nnrp_py-1.0.0rc3.tar.gz
  • Upload date:
  • Size: 20.9 MB
  • Tags: Source
  • Uploaded using Trusted Publishing? Yes
  • Uploaded via: twine/6.1.0 CPython/3.13.12

File hashes

Hashes for nnrp_py-1.0.0rc3.tar.gz
Algorithm Hash digest
SHA256 fb1547ba4af632b239ebcbab4cfb6bdd28ca1ff15f8532648b25d2993eb66a45
MD5 1061ce80250c2cbfc04f517ba7edff1e
BLAKE2b-256 838ba5e72da088e771ca3d38df912e090cee41fb2ba0ea2128a91dba69f9078e

See more details on using hashes here.

Provenance

The following attestation bundles were made for nnrp_py-1.0.0rc3.tar.gz:

Publisher: release.yml on NagareWorks/nnrp-py

Attestations: Values shown here reflect the state when the release was signed and may no longer be current.

File details

Details for the file nnrp_py-1.0.0rc3-py3-none-win_arm64.whl.

File metadata

  • Download URL: nnrp_py-1.0.0rc3-py3-none-win_arm64.whl
  • Upload date:
  • Size: 231.4 kB
  • Tags: Python 3, Windows ARM64
  • Uploaded using Trusted Publishing? Yes
  • Uploaded via: twine/6.1.0 CPython/3.13.12

File hashes

Hashes for nnrp_py-1.0.0rc3-py3-none-win_arm64.whl
Algorithm Hash digest
SHA256 8004ad9608c03b20d956ac15d9d170a5aafd4bd4a0205c98072c7039a1a58455
MD5 c3f18187837f283220ffe0e20b8d68cd
BLAKE2b-256 6246fef374e2b69d193f7f8ecb6519b1813d1ba7038e3bb415067c74b2b61cf3

See more details on using hashes here.

Provenance

The following attestation bundles were made for nnrp_py-1.0.0rc3-py3-none-win_arm64.whl:

Publisher: release.yml on NagareWorks/nnrp-py

Attestations: Values shown here reflect the state when the release was signed and may no longer be current.

File details

Details for the file nnrp_py-1.0.0rc3-py3-none-win_amd64.whl.

File metadata

  • Download URL: nnrp_py-1.0.0rc3-py3-none-win_amd64.whl
  • Upload date:
  • Size: 239.5 kB
  • Tags: Python 3, Windows x86-64
  • Uploaded using Trusted Publishing? Yes
  • Uploaded via: twine/6.1.0 CPython/3.13.12

File hashes

Hashes for nnrp_py-1.0.0rc3-py3-none-win_amd64.whl
Algorithm Hash digest
SHA256 97ad859dc6bacf1839017a85fc31f68669b754273c0d1c4b705957f483912b06
MD5 c8a123d0066127bf4e10b147e2ca3855
BLAKE2b-256 47728b3a5ee1b98c0728965deea99e622f2009b64b847adac56512fd08a58545

See more details on using hashes here.

Provenance

The following attestation bundles were made for nnrp_py-1.0.0rc3-py3-none-win_amd64.whl:

Publisher: release.yml on NagareWorks/nnrp-py

Attestations: Values shown here reflect the state when the release was signed and may no longer be current.

File details

Details for the file nnrp_py-1.0.0rc3-py3-none-win32.whl.

File metadata

  • Download URL: nnrp_py-1.0.0rc3-py3-none-win32.whl
  • Upload date:
  • Size: 234.9 kB
  • Tags: Python 3, Windows x86
  • Uploaded using Trusted Publishing? Yes
  • Uploaded via: twine/6.1.0 CPython/3.13.12

File hashes

Hashes for nnrp_py-1.0.0rc3-py3-none-win32.whl
Algorithm Hash digest
SHA256 0187c08b4c47743101cde1c57e916dd96a7b16267cc6f41a25926e25620e66dd
MD5 851cc69de57ef5e045a1a1170bb522aa
BLAKE2b-256 98934f7dae02c13b118841414aa16b82ecca1c50840f040738163b7aa3a2e97b

See more details on using hashes here.

Provenance

The following attestation bundles were made for nnrp_py-1.0.0rc3-py3-none-win32.whl:

Publisher: release.yml on NagareWorks/nnrp-py

Attestations: Values shown here reflect the state when the release was signed and may no longer be current.

File details

Details for the file nnrp_py-1.0.0rc3-py3-none-manylinux_2_28_i686.whl.

File metadata

File hashes

Hashes for nnrp_py-1.0.0rc3-py3-none-manylinux_2_28_i686.whl
Algorithm Hash digest
SHA256 91774aab24aa0387f5b951dac6d1c40fa6a98997e70eb58e507963fcde954ddd
MD5 6245f1d51f4220282c5d61bae2b4370d
BLAKE2b-256 25a30bddad2043b9224c41db182bd36ccb728799e3fdfe218d7e166e96208c06

See more details on using hashes here.

Provenance

The following attestation bundles were made for nnrp_py-1.0.0rc3-py3-none-manylinux_2_28_i686.whl:

Publisher: release.yml on NagareWorks/nnrp-py

Attestations: Values shown here reflect the state when the release was signed and may no longer be current.

File details

Details for the file nnrp_py-1.0.0rc3-py3-none-manylinux_2_28_armv7l.whl.

File metadata

File hashes

Hashes for nnrp_py-1.0.0rc3-py3-none-manylinux_2_28_armv7l.whl
Algorithm Hash digest
SHA256 c113278511b0d9dd3a4f72357615244f29884c18dd092223e581dc4d9ee264f2
MD5 bc66063b04758b5f3866f92b2d15929c
BLAKE2b-256 e02f82f326420232fadc15620ecd8aff25de5ec9ef4cba911a32ca7c121dc31a

See more details on using hashes here.

Provenance

The following attestation bundles were made for nnrp_py-1.0.0rc3-py3-none-manylinux_2_28_armv7l.whl:

Publisher: release.yml on NagareWorks/nnrp-py

Attestations: Values shown here reflect the state when the release was signed and may no longer be current.

File details

Details for the file nnrp_py-1.0.0rc3-py3-none-manylinux_2_28_aarch64.whl.

File metadata

File hashes

Hashes for nnrp_py-1.0.0rc3-py3-none-manylinux_2_28_aarch64.whl
Algorithm Hash digest
SHA256 e9899aeafd0d668f56c6a6ba899d707c53f479344c88f68f8ff192958ad03ba8
MD5 e058b33f1a31a19f43778b5631b183c7
BLAKE2b-256 17482e9054fa2c9140ddfc9bb11ea514b5426a568f54cdc455e6ef0ae92a9df7

See more details on using hashes here.

Provenance

The following attestation bundles were made for nnrp_py-1.0.0rc3-py3-none-manylinux_2_28_aarch64.whl:

Publisher: release.yml on NagareWorks/nnrp-py

Attestations: Values shown here reflect the state when the release was signed and may no longer be current.

File details

Details for the file nnrp_py-1.0.0rc3-py3-none-macosx_11_0_x86_64.whl.

File metadata

File hashes

Hashes for nnrp_py-1.0.0rc3-py3-none-macosx_11_0_x86_64.whl
Algorithm Hash digest
SHA256 05ae613b5b1591587d7799a176aa7cab8bb42167279cb515de6461c743fa4881
MD5 1d01c6e3c0cca619e2a1ee3ea0f2d05c
BLAKE2b-256 27a89251407b27f74705e5cadfeba23043ace44b7c271b81684b704a383ecb52

See more details on using hashes here.

Provenance

The following attestation bundles were made for nnrp_py-1.0.0rc3-py3-none-macosx_11_0_x86_64.whl:

Publisher: release.yml on NagareWorks/nnrp-py

Attestations: Values shown here reflect the state when the release was signed and may no longer be current.

File details

Details for the file nnrp_py-1.0.0rc3-py3-none-macosx_11_0_arm64.whl.

File metadata

File hashes

Hashes for nnrp_py-1.0.0rc3-py3-none-macosx_11_0_arm64.whl
Algorithm Hash digest
SHA256 20e889af69db9256746aea7232b348c71887a046464fc5c7631b16bfd55578fa
MD5 c7d60ba1b9312d9bc3915449d0a629bb
BLAKE2b-256 d231cfed9134ba39051da4bbefe9ca382b9506b6f163e28240a33ffd976b28ba

See more details on using hashes here.

Provenance

The following attestation bundles were made for nnrp_py-1.0.0rc3-py3-none-macosx_11_0_arm64.whl:

Publisher: release.yml on NagareWorks/nnrp-py

Attestations: Values shown here reflect the state when the release was signed and may no longer be current.

File details

Details for the file nnrp_py-1.0.0rc3-py3-none-ios_13_0_x86_64_iphonesimulator.whl.

File metadata

File hashes

Hashes for nnrp_py-1.0.0rc3-py3-none-ios_13_0_x86_64_iphonesimulator.whl
Algorithm Hash digest
SHA256 f11179ff4f0d9c36b5716f05159e01d2bc1eabb805512584a3d2151e19c9f72a
MD5 b3ee3c74b56a04faa39f4ca8df395692
BLAKE2b-256 bcaf71663c1ee1272f8009803f235e93444d20bcdfdb36716a3f3809779182c9

See more details on using hashes here.

Provenance

The following attestation bundles were made for nnrp_py-1.0.0rc3-py3-none-ios_13_0_x86_64_iphonesimulator.whl:

Publisher: release.yml on NagareWorks/nnrp-py

Attestations: Values shown here reflect the state when the release was signed and may no longer be current.

File details

Details for the file nnrp_py-1.0.0rc3-py3-none-ios_13_0_arm64_iphonesimulator.whl.

File metadata

File hashes

Hashes for nnrp_py-1.0.0rc3-py3-none-ios_13_0_arm64_iphonesimulator.whl
Algorithm Hash digest
SHA256 e49710e26c9b40b9b31a9efc660c3e72667c801ab8b90c4d905baf7b51812490
MD5 9dffe18efe4fdfff9b0b783b6b8faa5e
BLAKE2b-256 f09b3dae1f6e7c3f69cf735fe3cd5dc861697072df9f7c67765ec32c369d9b15

See more details on using hashes here.

Provenance

The following attestation bundles were made for nnrp_py-1.0.0rc3-py3-none-ios_13_0_arm64_iphonesimulator.whl:

Publisher: release.yml on NagareWorks/nnrp-py

Attestations: Values shown here reflect the state when the release was signed and may no longer be current.

File details

Details for the file nnrp_py-1.0.0rc3-py3-none-ios_13_0_arm64_iphoneos.whl.

File metadata

File hashes

Hashes for nnrp_py-1.0.0rc3-py3-none-ios_13_0_arm64_iphoneos.whl
Algorithm Hash digest
SHA256 2bd3ec3c1107622c86f2cd9848325ca35f70db35a4df11a8bdef3852ca4a4a76
MD5 179c32615b3a824066212d68b324997b
BLAKE2b-256 923fdbd691e14480abb28e7a5a7ed931d383868f3fc95aa372e480411de5f880

See more details on using hashes here.

Provenance

The following attestation bundles were made for nnrp_py-1.0.0rc3-py3-none-ios_13_0_arm64_iphoneos.whl:

Publisher: release.yml on NagareWorks/nnrp-py

Attestations: Values shown here reflect the state when the release was signed and may no longer be current.

File details

Details for the file nnrp_py-1.0.0rc3-py3-none-android_24_x86_64.whl.

File metadata

File hashes

Hashes for nnrp_py-1.0.0rc3-py3-none-android_24_x86_64.whl
Algorithm Hash digest
SHA256 c76fec328cb3ef7ff61c08952d50a59aea84b69964e6f131d16b2a9f07bf91cf
MD5 8de8619275318654801625275f9b23a3
BLAKE2b-256 78bd4e5d3efec81ed74d3852585a3d567b6833471e5ae5887e46c57a83551018

See more details on using hashes here.

Provenance

The following attestation bundles were made for nnrp_py-1.0.0rc3-py3-none-android_24_x86_64.whl:

Publisher: release.yml on NagareWorks/nnrp-py

Attestations: Values shown here reflect the state when the release was signed and may no longer be current.

File details

Details for the file nnrp_py-1.0.0rc3-py3-none-android_24_x86.whl.

File metadata

  • Download URL: nnrp_py-1.0.0rc3-py3-none-android_24_x86.whl
  • Upload date:
  • Size: 386.8 kB
  • Tags: Android API level 24+ x86, Python 3
  • Uploaded using Trusted Publishing? Yes
  • Uploaded via: twine/6.1.0 CPython/3.13.12

File hashes

Hashes for nnrp_py-1.0.0rc3-py3-none-android_24_x86.whl
Algorithm Hash digest
SHA256 035a28ee822ce77299658d2c3d3647c55dd7aed519190bc72f140bf8d2638841
MD5 1245f479b8f77ab3b2f891de99f39623
BLAKE2b-256 9ee823136e00444f7cc1eccb3a45b48dd445de6f312b7e3e215db4b1730bbcb6

See more details on using hashes here.

Provenance

The following attestation bundles were made for nnrp_py-1.0.0rc3-py3-none-android_24_x86.whl:

Publisher: release.yml on NagareWorks/nnrp-py

Attestations: Values shown here reflect the state when the release was signed and may no longer be current.

File details

Details for the file nnrp_py-1.0.0rc3-py3-none-android_24_armeabi_v7a.whl.

File metadata

File hashes

Hashes for nnrp_py-1.0.0rc3-py3-none-android_24_armeabi_v7a.whl
Algorithm Hash digest
SHA256 69ec74e788a53b6bb2d7144e1f4dbe98cf4cdfef825d2763258c2b85bb48ee8d
MD5 1fc33660d73c45a52b4f784f7b68dacd
BLAKE2b-256 506606f0be4a7838cfbb4a3c933876858b6ef840640bec70a95c5b3daed95333

See more details on using hashes here.

Provenance

The following attestation bundles were made for nnrp_py-1.0.0rc3-py3-none-android_24_armeabi_v7a.whl:

Publisher: release.yml on NagareWorks/nnrp-py

Attestations: Values shown here reflect the state when the release was signed and may no longer be current.

File details

Details for the file nnrp_py-1.0.0rc3-py3-none-android_24_arm64_v8a.whl.

File metadata

File hashes

Hashes for nnrp_py-1.0.0rc3-py3-none-android_24_arm64_v8a.whl
Algorithm Hash digest
SHA256 589e6524e2753b5ed228cd37e91896f1600f76020d6bade4928b00031de0b33c
MD5 c036567e1f9cefb6b29d1c7aa4d8473e
BLAKE2b-256 078e6497c7476e445ae8c04be9d6e267a513f3baa81f20c92afc005680851682

See more details on using hashes here.

Provenance

The following attestation bundles were made for nnrp_py-1.0.0rc3-py3-none-android_24_arm64_v8a.whl:

Publisher: release.yml on NagareWorks/nnrp-py

Attestations: Values shown here reflect the state when the release was signed and may no longer be current.

File details

Details for the file nnrp_py-1.0.0rc3-cp311-cp311-manylinux_2_28_x86_64.whl.

File metadata

File hashes

Hashes for nnrp_py-1.0.0rc3-cp311-cp311-manylinux_2_28_x86_64.whl
Algorithm Hash digest
SHA256 54cae11d74c23465c8046b14b35ffbaa68c8d8bb636edb27f690f71bea062aea
MD5 0d079bf41818a2cbcab75db0d9844252
BLAKE2b-256 38aead09c433c74b03266348e13b17be2fc1a5cc1096e6327b34f86d38945299

See more details on using hashes here.

Provenance

The following attestation bundles were made for nnrp_py-1.0.0rc3-cp311-cp311-manylinux_2_28_x86_64.whl:

Publisher: release.yml on NagareWorks/nnrp-py

Attestations: Values shown here reflect the state when the release was signed and may no longer be current.

Supported by

AWS Cloud computing and Security Sponsor Datadog Monitoring Depot Continuous Integration Fastly CDN Google Download Analytics Pingdom Monitoring Sentry Error logging StatusPage Status page