Skip to main content
Pre-release

This release is a pre-release and may not be stable for production use.

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: schema/profile descriptor views and 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.

import asyncio

from nnrp.client import (
    NativeClientOptions,
    NativeClientSessionOptions,
    SubmitIdentity,
    SubmitPolicy,
    SubmitRequest,
    TokenChunk,
    TokenSubmitInput,
    connect_native_client_connection,
)


async def main() -> None:
    with connect_native_client_connection(
        NativeClientOptions("nnrp://runtime.example/session/default")
    ) as connection:
        session = await connection.open_session(
            NativeClientSessionOptions(requested_session_id=42)
        )
        request = SubmitRequest.token(
            TokenSubmitInput(
                identity=SubmitIdentity(operation_id=1001, frame_id=1),
                policy=SubmitPolicy(),
                chunks=(TokenChunk(b"token-or-typed-payload-bytes"),),
            )
        )
        result = connection.submit_and_poll_result(session, request, max_events=8)
        print(result.terminal_state)


asyncio.run(main())

The native helpers provide:

  1. connect_native_client_connection() for one Rust-backed connection that can own multiple sessions.
  2. await 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() and NativeClientConnection.cancel_operation() for operation-aware cancellation.
  7. Named Preview4 runtime-control helpers for scheduling, route hints, execution hints, capability negotiation, and profile degradation. Raw control codes are internal.

By default the native loader searches nnrp/native_artifacts/<os>-<arch>/ inside the installed package. Set NNRP_NATIVE_ARTIFACT_ROOT only when testing an external artifact tree. Public host APIs require the native runtime; fallback injection is private test infrastructure.

The production binding is the ABI 4 carrier/role surface exposed through ctypes. A provider artifact opens the TCP, QUIC, IPC, or WebSocket carrier, then transfers that carrier to the Rust client or server role. Submit, cancellation, server receive/result delivery, and event polling remain coarse role calls; the Python package does not ship a second compact-result runtime or a compiled CFFI side path.

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.

Preview4 Runtime Controls

Client control helpers build the frozen preview4 metadata payloads and send one coarse nnrp_runtime_frame_send ABI call through the selected session. Applications do not construct raw frames or pass control codes:

import asyncio

from nnrp.client import NativeClientOptions, NativeClientSessionOptions, connect_native_client_connection


async def configure_session() -> None:
    with connect_native_client_connection(
        NativeClientOptions("nnrp://runtime.example/session/default")
    ) as connection:
        session = await connection.open_session(
            NativeClientSessionOptions(requested_session_id=42)
        )
        connection.update_runtime_priority(
            session,
            operation_id=1001,
            control_sequence=1,
            priority_class=2,
            priority_delta=4,
        )
        connection.cancel_runtime_operation(
            session,
            operation_id=1001,
            control_sequence=2,
            reason_code=7,
            diagnostic=b"superseded by fresher frame",
        )


asyncio.run(configure_session())

The accepted server operation owns progress, partial, terminal, and drop replies. The server session retains session-scoped controls such as pressure and credit updates:

from nnrp.runtime import (
    PartialResultMetadata,
    PressureMetadata,
    ProgressMetadata,
    ResultDropReasonCode,
    ResultDropReasonMetadata,
    RuntimeRole,
)

async def handle_next_operation(session):
    operation = await session.receive_submit()
    await operation.send_progress(
        ProgressMetadata(operation.operation_id, 1, 2, 2500, 0, len(b"tile pass 1/4")),
        b"tile pass 1/4",
    )
    await operation.send_partial_result(
        PartialResultMetadata(operation.operation_id, 2, 33, 1, len(b"partial payload snapshot"), 0),
        b"partial payload snapshot",
    )
    await operation.send_result_drop(
        ResultDropReasonMetadata(
            operation.operation_id,
            3,
            ResultDropReasonCode.DEADLINE_EXPIRED,
            RuntimeRole.RUNTIME,
            0,
            len(b"expired before delivery"),
        ),
        b"expired before delivery",
    )

    # Scope 0 applies connection-wide; use an operation id for operation-scoped pressure.
    session.send_backpressure(
        PressureMetadata(
            scope_id=0,
            credit_window=8,
            pressure_level=2,
            pressure_reason=5,
            retry_after_ms=0,
            flags=0,
        )
    )

These helpers are runtime-control API conveniences, not a pure-Python runtime replacement. Public host APIs require the packaged native artifacts; packet builders under nnrp.core remain for fixtures, diagnostics, and conformance tooling.

Preview4 Transport Providers

Preview4 native artifacts are transport scoped. Python discovers installed providers from the packaged Rust artifact manifests and rejects names that are not advertised by the artifact tree:

from nnrp import (
	NativeTransportCandidateReadiness,
	NativeTransportSelectionOptions,
	TransportId,
	TransportPolicy,
	diagnose_nnrp_endpoint_support,
	discover_native_transport_providers,
	select_native_transport_provider,
)

providers = discover_native_transport_providers()
selection = select_native_transport_provider(
	NativeTransportSelectionOptions(
		peer_supported_transports=(TransportId.TCP,),
		policy=TransportPolicy.AUTO,
		requested_max_frame_bytes=None,
		candidate_readiness=tuple(
			NativeTransportCandidateReadiness.ready(provider) for provider in providers
		),
		probe_observations=(),
	)
)
support = diagnose_nnrp_endpoint_support("nnrps://runtime.example/session/default")

print([(provider.name, provider.transport_name) for provider in providers])
print(selection.selected_transport_name, selection.diagnostic)
print(support.endpoint.authority, support.available)

Installations with a single eligible provider select it directly. Multi-provider selection uses a TransportPolicy together with complete readiness and probe evidence. A provider descriptor keeps package identity (name) separate from the canonical carrier identity (transport_name / transport_id) and reports availability, owned library path, cost/preference hints, limits, and platform limitations. It is not a configuration flag over hidden shared transport logic.

Application-facing endpoints use nnrp:// or nnrps://. Provider-local locators such as unix://, npipe://, ws://, and wss:// are lower-level diagnostics, conformance fixture inputs, or explicit provider overrides. Their helper validates URI shape and exposes diagnostic skip messages without pretending a missing native provider passed a smoke test.

from nnrp import diagnose_native_transport_endpoint_support

support = diagnose_native_transport_endpoint_support("wss://runtime.example/nnrp")
if not support.available:
	print(support.skip_reason)

TCP, QUIC, IPC, and WebSocket keep their own native provider slots. Each installed transport artifact owns its carrier implementation, and live connect/listen paths invoke that provider rather than treating the package as a feature flag.

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:

import asyncio

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


async def use_cache_and_schema() -> None:
    with connect_native_client_connection(
        NativeClientOptions("nnrp://runtime.example/session/default")
    ) as connection:
        session = await connection.open_session(
            NativeClientSessionOptions(requested_session_id=42)
        )
        cache = session.cache_backend(now_ms=10_000, ttl_ms=30_000)
        identity = CacheObjectIdentity(cache_namespace=1, object_kind=1, cache_key_hi=0, cache_key_lo=7)
        lease = cache_query(cache, identity)
        if lease.succeeded and lease.lease is not None and lease.object_version is not None:
            lease.lease.validate_version(lease.object_version.object_version)
            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))


asyncio.run(use_cache_and_schema())

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 has exactly three fields: operation_id, terminal_state, and event. terminal_state is one of success, cancelled, dropped, or error. The closed event union contains either the complete wire NativeRuntimeEvent or an OperationLifecycleEvent; inspect it with as_runtime() or as_lifecycle() instead of relying on flattened payload, frame, metadata, or diagnostic fields.

Runtime Object And Cache Metadata

Preview4 runtime object and cache helpers live in nnrp.runtime. They encode and decode the frozen runtime-control, object, and cache metadata shapes without routing hot paths through JSON:

from nnrp.core import MessageType
from nnrp.runtime import (
	CacheReferenceMetadata,
	CacheReuseScope,
	decode_runtime_object_metadata,
	encode_runtime_object_metadata,
)

metadata = CacheReferenceMetadata(
	cache_key_hi=2,
	cache_key_lo=3,
	profile_id=19,
	reuse_scope=CacheReuseScope.SESSION,
	lease_id=9,
	producer_trace_id=77,
	expiration_hint_ms=5000,
	metadata_bytes=0,
	flags=0,
)
payload = encode_runtime_object_metadata(MessageType.CACHE_REFERENCE, metadata)
decoded = decode_runtime_object_metadata(MessageType.CACHE_REFERENCE, payload)
assert decoded.metadata == metadata

Cache references are an explicit workload behavior. They help when producers and consumers can reuse a stable object identity or lease, but they are not a universal latency guarantee; high-churn payloads should record cache misses as typed events and continue through the normal result path.

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. CacheLeaseDescriptor preserves the native object version, lease id, owner scope/id, grant timestamp, and TTL; expires_at_ms, is_expired(), and validate_version() provide the frozen local validation semantics. 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.

import asyncio

from nnrp.client import NativeClientOptions, NativeClientSessionOptions, connect_native_client_connection


async def open_sessions() -> None:
    with connect_native_client_connection(
        NativeClientOptions("nnrp://runtime.example/session/default")
    ) as connection:
        interactive, batch = await asyncio.gather(
            connection.open_session(NativeClientSessionOptions(requested_session_id=10)),
            connection.open_session(NativeClientSessionOptions(requested_session_id=11)),
        )
        print(interactive.requested_session_id, batch.requested_session_id)


asyncio.run(open_sessions())

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

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.0rc4.post20.tar.gz (529.2 kB 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.0rc4.post20-py3-none-win_arm64.whl (6.2 MB view details)

Uploaded Python 3Windows ARM64

nnrp_py-1.0.0rc4.post20-py3-none-win_amd64.whl (6.7 MB view details)

Uploaded Python 3Windows x86-64

nnrp_py-1.0.0rc4.post20-py3-none-win32.whl (5.5 MB view details)

Uploaded Python 3Windows x86

nnrp_py-1.0.0rc4.post20-py3-none-manylinux_2_28_x86_64.whl (7.8 MB view details)

Uploaded Python 3manylinux: glibc 2.28+ x86-64

nnrp_py-1.0.0rc4.post20-py3-none-manylinux_2_28_i686.whl (7.8 MB view details)

Uploaded Python 3manylinux: glibc 2.28+ i686

nnrp_py-1.0.0rc4.post20-py3-none-manylinux_2_28_armv7l.whl (7.2 MB view details)

Uploaded Python 3manylinux: glibc 2.28+ ARMv7l

nnrp_py-1.0.0rc4.post20-py3-none-manylinux_2_28_aarch64.whl (7.8 MB view details)

Uploaded Python 3manylinux: glibc 2.28+ ARM64

nnrp_py-1.0.0rc4.post20-py3-none-macosx_11_0_x86_64.whl (7.2 MB view details)

Uploaded Python 3macOS 11.0+ x86-64

nnrp_py-1.0.0rc4.post20-py3-none-macosx_11_0_arm64.whl (6.9 MB view details)

Uploaded Python 3macOS 11.0+ ARM64

nnrp_py-1.0.0rc4.post20-py3-none-ios_13_0_x86_64_iphonesimulator.whl (36.2 MB view details)

Uploaded Python 3iOS 13.0+ x86-64 Simulator

nnrp_py-1.0.0rc4.post20-py3-none-ios_13_0_arm64_iphonesimulator.whl (36.1 MB view details)

Uploaded Python 3iOS 13.0+ ARM64 Simulator

nnrp_py-1.0.0rc4.post20-py3-none-ios_13_0_arm64_iphoneos.whl (36.2 MB view details)

Uploaded Python 3iOS 13.0+ ARM64 Device

nnrp_py-1.0.0rc4.post20-py3-none-android_24_x86_64.whl (7.7 MB view details)

Uploaded Android API level 24+ x86-64Python 3

nnrp_py-1.0.0rc4.post20-py3-none-android_24_x86.whl (7.7 MB view details)

Uploaded Android API level 24+ x86Python 3

nnrp_py-1.0.0rc4.post20-py3-none-android_24_armeabi_v7a.whl (6.3 MB view details)

Uploaded Android API level 24+ ARM EABI v7aPython 3

nnrp_py-1.0.0rc4.post20-py3-none-android_24_arm64_v8a.whl (7.6 MB view details)

Uploaded Android API level 24+ ARM64 v8aPython 3

File details

Details for the file nnrp_py-1.0.0rc4.post20.tar.gz.

File metadata

  • Download URL: nnrp_py-1.0.0rc4.post20.tar.gz
  • Upload date:
  • Size: 529.2 kB
  • Tags: Source
  • Uploaded using Trusted Publishing? Yes
  • Uploaded via: twine/7.0.0 CPython/3.13.14

File hashes

Hashes for nnrp_py-1.0.0rc4.post20.tar.gz
Algorithm Hash digest
SHA256 6e0e5ee4227aaa3d37a792be57e0a4bcc85d7770f32cdf42134b054ca88f8795
MD5 11893519dd56c012352c518185f3df83
BLAKE2b-256 1c5407f9b9f015be234aacf8a8559ab4835876004c82a624193c1370256ef6d3

See more details on using hashes here.

Provenance

The following attestation bundles were made for nnrp_py-1.0.0rc4.post20.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.0rc4.post20-py3-none-win_arm64.whl.

File metadata

File hashes

Hashes for nnrp_py-1.0.0rc4.post20-py3-none-win_arm64.whl
Algorithm Hash digest
SHA256 5d8bae5aa38b7cef880b4cfeddbb8c5443212ad885a426d10c1fbfcd5c84f935
MD5 5f2dab3b6e4abda1fec09ffd8d342cd3
BLAKE2b-256 c2b0d85f94e55305862597c80df325757fdd263d83793ca0f2d6d05465d52e48

See more details on using hashes here.

Provenance

The following attestation bundles were made for nnrp_py-1.0.0rc4.post20-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.0rc4.post20-py3-none-win_amd64.whl.

File metadata

File hashes

Hashes for nnrp_py-1.0.0rc4.post20-py3-none-win_amd64.whl
Algorithm Hash digest
SHA256 8f6ddde876cd6064a86386101f78b049de19440d270d709e7031161f205cdd82
MD5 949349ce2bfc73b82a7976005a26138b
BLAKE2b-256 7242e370bc81437d161dde8cbfe1d1296585182f33859f93de27d1c4a23b472c

See more details on using hashes here.

Provenance

The following attestation bundles were made for nnrp_py-1.0.0rc4.post20-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.0rc4.post20-py3-none-win32.whl.

File metadata

File hashes

Hashes for nnrp_py-1.0.0rc4.post20-py3-none-win32.whl
Algorithm Hash digest
SHA256 03541772cf3ac15f35adbe5922910d6a4950a06e4ab9389a07a1b11519898e5f
MD5 144ff37d95fca9a470232180e4a9063c
BLAKE2b-256 37624e70d1f3ccbf7bf6a607041579e47409bbdf00c40b34badfa32775b82021

See more details on using hashes here.

Provenance

The following attestation bundles were made for nnrp_py-1.0.0rc4.post20-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.0rc4.post20-py3-none-manylinux_2_28_x86_64.whl.

File metadata

File hashes

Hashes for nnrp_py-1.0.0rc4.post20-py3-none-manylinux_2_28_x86_64.whl
Algorithm Hash digest
SHA256 89f6aa664684f08127fc0d1d5f1ed260ab9be080f492a4a48acd8046e916de27
MD5 b8c2619e7f8a458628dc349fed3cba19
BLAKE2b-256 9ebefb087f71bc6c3b0b448874ce2be01371909ffb5d8e5d9c3ed0ea823666c7

See more details on using hashes here.

Provenance

The following attestation bundles were made for nnrp_py-1.0.0rc4.post20-py3-none-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.

File details

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

File metadata

File hashes

Hashes for nnrp_py-1.0.0rc4.post20-py3-none-manylinux_2_28_i686.whl
Algorithm Hash digest
SHA256 09f1a2c81613c14eaacd99485da03ee7f3bfa79b82080f0e18257ae039ed58e4
MD5 f1d5a6741daa561d5c074bdbbca9f646
BLAKE2b-256 39f7e5d8ed35ba209c254930b0c09dabe194c73be09b63305c4896abf54cffdc

See more details on using hashes here.

Provenance

The following attestation bundles were made for nnrp_py-1.0.0rc4.post20-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.0rc4.post20-py3-none-manylinux_2_28_armv7l.whl.

File metadata

File hashes

Hashes for nnrp_py-1.0.0rc4.post20-py3-none-manylinux_2_28_armv7l.whl
Algorithm Hash digest
SHA256 c52e0e899c712137bd93b2d569b150350d1ab54d3c61aa0c62571bfc6dbce136
MD5 e0d34858212b0361fcdf1cac1637a016
BLAKE2b-256 a9ec6510ac59ceb675657ed899e9e408fbb59dae57007d6c95d6ae074dca4d29

See more details on using hashes here.

Provenance

The following attestation bundles were made for nnrp_py-1.0.0rc4.post20-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.0rc4.post20-py3-none-manylinux_2_28_aarch64.whl.

File metadata

File hashes

Hashes for nnrp_py-1.0.0rc4.post20-py3-none-manylinux_2_28_aarch64.whl
Algorithm Hash digest
SHA256 f23e437a571dc9eee69c59af8814de9a26ae0178d15bf65d9988c435bc45e20a
MD5 05a456fd8fa5352f89696449b389089d
BLAKE2b-256 43e6ab1149ceb21782791af1296785681c64f790a4901d30780cd675005baa5b

See more details on using hashes here.

Provenance

The following attestation bundles were made for nnrp_py-1.0.0rc4.post20-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.0rc4.post20-py3-none-macosx_11_0_x86_64.whl.

File metadata

File hashes

Hashes for nnrp_py-1.0.0rc4.post20-py3-none-macosx_11_0_x86_64.whl
Algorithm Hash digest
SHA256 5c7c44b459dc295b92e175da3792eea662c7920b82c2781edca91bcb4869ca6b
MD5 438531479af4a98bbbb6de172cfad6bb
BLAKE2b-256 21dec87f7bc45f3d19e6d64e6ffbd40093200d081eff55d3197e1287f1192bb6

See more details on using hashes here.

Provenance

The following attestation bundles were made for nnrp_py-1.0.0rc4.post20-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.0rc4.post20-py3-none-macosx_11_0_arm64.whl.

File metadata

File hashes

Hashes for nnrp_py-1.0.0rc4.post20-py3-none-macosx_11_0_arm64.whl
Algorithm Hash digest
SHA256 ba34d299c77089df93d25289297d23ba018d107ad82d2543bfdba57d7b5ff56d
MD5 c90d6d7d2d1d94396d8e71695dcffe66
BLAKE2b-256 5af174ba3bc8ee81f29ff95700c0ccd529cfa342f93acb2da31d1c64446ff6cb

See more details on using hashes here.

Provenance

The following attestation bundles were made for nnrp_py-1.0.0rc4.post20-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.0rc4.post20-py3-none-ios_13_0_x86_64_iphonesimulator.whl.

File metadata

File hashes

Hashes for nnrp_py-1.0.0rc4.post20-py3-none-ios_13_0_x86_64_iphonesimulator.whl
Algorithm Hash digest
SHA256 563c0216f842559dfbfcd80b6928fc3afd93ae414c4d31376a1127c34c8fa1f5
MD5 d06f973eae6828d037e2ee61ac432e6b
BLAKE2b-256 8397c8da49f9ed90891c5d42830b50bb028a7ff4bc44234df69d28fee0629db5

See more details on using hashes here.

Provenance

The following attestation bundles were made for nnrp_py-1.0.0rc4.post20-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.0rc4.post20-py3-none-ios_13_0_arm64_iphonesimulator.whl.

File metadata

File hashes

Hashes for nnrp_py-1.0.0rc4.post20-py3-none-ios_13_0_arm64_iphonesimulator.whl
Algorithm Hash digest
SHA256 d4aa771511856990c6feef14e5fe262597f9d4357894e1824600de97ac29968e
MD5 8984e6e4b7c8eb6c03fe5944320e1ee2
BLAKE2b-256 0619ca0d2c5d8c3ae596f840da9514dde96a2a1ca31ab25e697ec695e12ff431

See more details on using hashes here.

Provenance

The following attestation bundles were made for nnrp_py-1.0.0rc4.post20-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.0rc4.post20-py3-none-ios_13_0_arm64_iphoneos.whl.

File metadata

File hashes

Hashes for nnrp_py-1.0.0rc4.post20-py3-none-ios_13_0_arm64_iphoneos.whl
Algorithm Hash digest
SHA256 1ea001f538c6a000f2496ba6862bf092740f104e7b31a9e8ef3f375e30543260
MD5 f026512d7cc6c43e0a513acd7fdd8e04
BLAKE2b-256 5a991aa5550a807c8e91e7fa0cbce26bc967655abcab2151b9976d27eab9b78a

See more details on using hashes here.

Provenance

The following attestation bundles were made for nnrp_py-1.0.0rc4.post20-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.0rc4.post20-py3-none-android_24_x86_64.whl.

File metadata

File hashes

Hashes for nnrp_py-1.0.0rc4.post20-py3-none-android_24_x86_64.whl
Algorithm Hash digest
SHA256 7a6c50129382bd58896721b88acca00470e3bb29b5faa3b7bedfb9def073b489
MD5 1abc65fd5bd0e5ed8562377640d5da67
BLAKE2b-256 d4fc39cc3749d26731aff6f81cffcb39ff49b7ba519892aa5ef45553d0a13fe4

See more details on using hashes here.

Provenance

The following attestation bundles were made for nnrp_py-1.0.0rc4.post20-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.0rc4.post20-py3-none-android_24_x86.whl.

File metadata

File hashes

Hashes for nnrp_py-1.0.0rc4.post20-py3-none-android_24_x86.whl
Algorithm Hash digest
SHA256 608f3ceba16a1f3a40137677334770fd20c69a1291abb10ccdec432c1ab4ced8
MD5 70e9b5bb5e2b9656669ff7cfe456b850
BLAKE2b-256 14df753df2c5f296626dc7ab7dad77b3ebf04a4a0b04eb11432dfae9c8832919

See more details on using hashes here.

Provenance

The following attestation bundles were made for nnrp_py-1.0.0rc4.post20-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.0rc4.post20-py3-none-android_24_armeabi_v7a.whl.

File metadata

File hashes

Hashes for nnrp_py-1.0.0rc4.post20-py3-none-android_24_armeabi_v7a.whl
Algorithm Hash digest
SHA256 bd58757f1c8d0aa359c2800583c74e950979e4987f4d07124f0a6d0ae008c2f9
MD5 110494b11145a40bb03e0de61fec3466
BLAKE2b-256 755c874746df10c9b7f8d8ed0a816fbc7678115edd9cfbb14cd9ec805a484042

See more details on using hashes here.

Provenance

The following attestation bundles were made for nnrp_py-1.0.0rc4.post20-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.0rc4.post20-py3-none-android_24_arm64_v8a.whl.

File metadata

File hashes

Hashes for nnrp_py-1.0.0rc4.post20-py3-none-android_24_arm64_v8a.whl
Algorithm Hash digest
SHA256 731c1d73483d2499827d641f474ae80abcfd56fb30458df5ba5cc6f6c89880d0
MD5 6d67e8108b09c0d5a33086ee946d9793
BLAKE2b-256 7ee8fe48a5f817d960fd2a0d3e867b48cd20c0ab3bef045b77bb3c3dc9997636

See more details on using hashes here.

Provenance

The following attestation bundles were made for nnrp_py-1.0.0rc4.post20-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.
Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page