| Name | zvic JSON |
| Version |
2025.34
JSON |
| download |
| home_page | None |
| Summary | Zero-Version Interface Contracts (ZVIC) - signature-based compatibility for Python modules. |
| upload_time | 2025-08-20 15:25:03 |
| maintainer | None |
| docs_url | None |
| author | Anselm Kiefner |
| requires_python | >=3.12 |
| license | None |
| keywords |
|
| VCS |
|
| bugtrack_url |
|
| requirements |
No requirements were recorded.
|
| Travis-CI |
No Travis.
|
| coveralls test coverage |
No coveralls.
|
[](LICENSE) [](https://www.python.org/)
# ZVIC
***ZVIC: Runtime interface compatibility for Python modules—no version numbers required.***
Zero-Version Interface Contracts (ZVIC) is both a project and a paradigm for signature-based compatibility in Python modules. ZVIC enables safe, dynamic code reuse and interface stability without version numbers, using runtime verification of callable structure.
License: MIT — see the `LICENSE` file for details (SPDX: MIT).
## Key Concepts
- **Zero-Version Interface Contracts (ZVIC):** Manages code compatibility without version numbers, relying on signature hashes and runtime checks. Contracts are verified at definition time and dynamically at runtime.
## Who Should Use ZVIC?
- Library authors who want to guarantee interface compatibility without versioning headaches.
- Teams practicing hot-reload or rapid deployment of Python modules.
- Anyone needing robust, runtime-checked API contracts for Python code.
## Goals
- Eliminate the need for semantic versioning in shared code
- Enable safe, hot-reloadable modules
- Provide runtime guarantees for interface compatibility
- Facilitate rapid development and deployment cycles
## Installation & requirements
- Requirements:
- Python 3.12+
- Install (user):
```sh
pip install zvic
```
- Install (developer / editable):
1. Create and activate a virtual environment
- Windows (PowerShell):
```powershell
py -3.12 -m venv .venv
.\.venv\Scripts\Activate.ps1
```
- Unix / macOS:
```sh
python3 -m venv .venv
source .venv/bin/activate
```
2. Install the package in editable mode:
```sh
pip install -e .
```
If you want CrossHair support for semantic constraint analysis (optional), install the extra:
```sh
pip install .[crosshair]
```
### Quickstart
For a minimal programmatic check you can use the following snippet (run from the repo root):
```py
from pathlib import Path
from zvic import load_module
from zvic.compatibility import is_compatible
from zvic.exception import SignatureIncompatible
a = load_module(Path('tests/stuff/mod_a.py'), 'mod_a')
b = load_module(Path('tests/stuff/mod_b.py'), 'mod_b')
try:
is_compatible(a.P2, b.P2)
print('compatible')
except SignatureIncompatible as e:
print('incompatible:')
print(e.to_json())
```
## Canonicalization & Compatibility
Function signatures are canonicalized to ensure consistent interface identification and compatibility checks. See the [Canonicalization & Compatibility Spec](docs/specs/spec-04-Canonicalization-Compatibility.md) for details and compatibility rules.
## Compatibility testing levels
ZVIC tests compatibility at multiple levels to give consumers high confidence before accepting a new module or version. The test strategy is deliberate and layered so that regressions are caught early and explained clearly.
- Public interface presence
- Modules are compared by their public attributes (respecting `__all__` when present). Any public attribute present in A but missing from B is reported as an incompatibility.
- Callable-level checks (structural)
- Callables (functions, methods, class `__call__`) are checked for signature compatibility. This covers parameter kinds (positional-only, positional-or-keyword, keyword-only), `*args`/`**kwargs`, default values, and parameter names where appropriate.
- `are_params_compatible()` implements the scenario-based rules from the spec and raises structured errors when B cannot accept all calls that A accepts.
- Type normalization and compatibility
- A type-normalization layer canonicalizes runtime annotation types to a uniform schema.
- `is_type_compatible()` implements rules such as: exact-type equality, allowed widening (derived→base contravariant acceptance), disallowed narrowing (base→derived), container invariance for invariants (e.g., `list[int]`), and ABC-aware acceptance.
- Constraint checks (Annotated)
- Constraint checking (Annotated)
- ZVIC recognizes `typing.Annotated[T, constraint]` forms and will transform inline call-style annotations into `Annotated[...]` during module loading when necessary.
- Constraint checking is best-effort: if the optional CrossHair analyser is installed, ZVIC will attempt a semantic verification (searching for counterexamples). If CrossHair is not available or cannot analyze a predicate, ZVIC falls back to deterministic heuristics (for example numeric/length comparisons) and ultimately to exact-match of the constraint expression.
- Class and enum checks
- Classes are compared for missing methods, and important special call sites such as `__init__` and `__call__` are compared recursively.
- Enum compatibility ensures member presence and value stability (we require that names present in A also exist in B and that their underlying values remain equal), while allowing reordering or new additional members in B.
- End-to-end tests
- The test-suite includes unit tests that exercise canonicalization, parameter scenarios, type compatibility edge-cases, and small integration examples. See `tests/` for examples and `docs/specs/spec-08-Test-Plan.md` for the test plan.
## How to run the test-suite
From the repository root:
```sh
pytest -q
```
Run a single test file (example):
```sh
pytest tests/test_spec08_compatibility.py -q
```
Optional: run an individual test by name with `-k`.
## Constraint checking and security - BEWARE MAGIC
Take this example:
def foo(x: int(_ < 10)) -> int(_ < 10):
return x * 2
Note that the `_ < 10` must be a valid Python expression (and thus is valid Python syntax, even though it looks weird!), but it is not evaluated in this context. With `from __future__ import annotations`, the whole annotation is treated as a string. ZVIC extracts this part and transforms it - first we append it to the docstring as pre/post conditions for crosshair to analyze "statically", second we transform the expression into a valid `assert` for runtime checking, if the interpreter is running in debug (not-optimized) mode.
If CrossHair is present, ZVIC will try to use it to search for counterexamples; if CrossHair is not present or cannot handle the predicate, ZVIC uses deterministic heuristics (numeric/length comparisons) and finally requires an exact expression match as a last resort.
## Security note
ZVIC performs runtime annotation resolution and, in some code paths, evaluates constraint expressions. This can execute arbitrary code from the loaded module. ***Do not run ZVIC against untrusted code without an appropriate sandbox***. If you must inspect untrusted modules, consider running ZVIC in an isolated environment (container, VM, or restricted subprocess). Since ZVIC also makes use of eval() to check type compatibility in dynamic contexts, be aware that this can execute arbitrary code from the module being checked even if you don't make use of constraints - **exercise caution**.
## Runtime requirements and packaging
- Python: 3.12+
- Install locally (editable):
```sh
pip install -e .
```
## Release notes and changelog
See `CHANGELOG.md` for release history and the summary of specs implemented in each release.
## Examples (from spec-08 tests)
Below are small, representative examples taken from the `spec-08` compatibility tests in `tests/stuff/` with the expected ZVIC behaviour.
- Compatible example (P1): positional-only parameters, same required/total — compatible, different names
```py
# Module A
def P1(a, b, /):
pass
# Module B
def P1(x, y, /):
pass
# Expected: is_compatible(mod_a.P1, mod_b.P1) -> no exception (compatible)
```
- Incompatible example (P2): B adds a required parameter — incompatible
```py
# Module A
def P2(a, b, /):
pass
# Module B
def P2(x, y, z, /):
pass
# Expected: is_compatible(mod_a.P2, mod_b.P2) -> raises SignatureIncompatible
# Typical diagnostic (ZVIC will raise `SignatureIncompatible` with context):
# {
# "message": "B has more required parameters than A",
# "context": {"A": "(a, b, /)", "B": "(x, y, z, /)"},
# "error_id": "ZV1001",
# }
```
- Constraint narrowing example (C4): A permits values < 20, B restricts to < 10 — incompatible
```py
# Module A
def C4(a: int(_ < 20)):
pass
# Module B
def C4(a: int(_ < 10)):
pass
# Expected: is_compatible(mod_a.C4, mod_b.C4) -> raises SignatureIncompatible
# Typical diagnostic message string produced by ZVIC:
# "Constraint mismatch for parameter a: _ < 20 vs _ < 10 (B is narrower and thus incompatible: some inputs that A accepts will not be accepted by B)"
```
## Try the examples
You can run a small convenience script that loads the real `tests/stuff` modules and prints compatibility results for a few spec-08 scenarios.
From the repository root (PowerShell example):
```powershell
py -3.12 examples/run_spec08_examples.py
```
Or, if your default python interpreter is Python >= 3.12 and on PATH:
```sh
py examples/run_spec08_examples.py
```
Sample output (trimmed):
--- Example: P1 ---
Result: compatible (no exception)
--- Example: P2 ---
Result: incompatible — diagnostic:
{
"error_id": "ZV1001",
"type": "SignatureIncompatible",
"severity": "error",
"message": "B has more required parameters than A",
"context": {"A": "(a, b, /)", "B": "(x, y, z, /)", "llm_hint": "..."},
...
}
--- Example: C4 ---
Result: incompatible — diagnostic:
{
"error_id": "ZV1001",
"type": "SignatureIncompatible",
"severity": "error",
"message": "Constraint mismatch for parameter a: _ < 20 vs _ < 10 (B is narrower and thus incompatible: some inputs that A accepts will not be accepted by B)",
...
}
## Project status
Stability: Beta
- Development status: actively developed and maintained. The test-suite runs locally and the repository currently has a comprehensive unit test suite, with all tests passing.
- Test coverage: unit tests exercise canonicalization, compatibility scenarios, and edge-cases.
- API stability: not guaranteed. Public APIs may change between releases as the project iterates on the specification and compatibility rules — please pin versions for production use and run the test-suite when upgrading.
- Recommended use: evaluation, experimentation, and integration testing. For critical production use, perform an acceptance pass and pin a released version.
- Contributing: contributions, issues, and PRs are welcome; see `CHANGELOG.md` and the `docs/specs/` for the current design decisions.
## Project Structure
- `README.md` - this document
- `src/` - Main source code
- `tests/` - Test suite (unit, integration, TDD, quick tests)
- `docs/specs/` - Detailed specifications
- `pyproject.toml` - Build and packaging configuration
- `setup.py` - Minimal legacy packaging script
- `CHANGELOG.md` - Release notes and change history
- `examples/` - Example scripts and usage patterns
## Further Reading
- [Spec 01: Introduction](docs/specs/spec-01-Introduction.md)
- [Spec 02: SDFP Principles](docs/specs/spec-02-SDFP-Principles.md)
- [Spec 03: ZVIC Contracts](docs/specs/spec-03-ZVIC-Contracts.md)
- [Spec 04: Canonicalization & Compatibility](docs/specs/spec-04-Canonicalization-Compatibility.md)
## Versioning Scheme
ZVIC uses a CalVer versioning scheme: `YYYY.0W[.patchN/devN/rcN]`, where:
- `YYYY` is the year
- `0W` is the zero-padded ISO week number
- Optional `.patchN`, `.devN`, `.rcN` for patches, dev, or release candidates
For example, `2025.26` corresponds to week 26 of 2025. This mirrors the structure of our Scrum logs (see `/docs/scrum/README.md`).
# Office Hours
You can also contact me one-on-one! Check my [office hours](https://calendly.com/amogorkon/officehours) to set up a meeting :-)
If you have questions also feel free to use the github issues or the [ZVIC Discussions](https://github.com/amogorkon/ZVIC/discussions).
***Enjoy!***
Raw data
{
"_id": null,
"home_page": null,
"name": "zvic",
"maintainer": null,
"docs_url": null,
"requires_python": ">=3.12",
"maintainer_email": null,
"keywords": null,
"author": "Anselm Kiefner",
"author_email": null,
"download_url": "https://files.pythonhosted.org/packages/41/89/c03ce32ddca1be8672332ceea0cdf53e237abfd1193cc37f9468f1943456/zvic-2025.34.tar.gz",
"platform": null,
"description": "[](LICENSE) [](https://www.python.org/)\n\n# ZVIC\n\n***ZVIC: Runtime interface compatibility for Python modules\u2014no version numbers required.***\n\nZero-Version Interface Contracts (ZVIC) is both a project and a paradigm for signature-based compatibility in Python modules. ZVIC enables safe, dynamic code reuse and interface stability without version numbers, using runtime verification of callable structure.\n\nLicense: MIT \u2014 see the `LICENSE` file for details (SPDX: MIT).\n\n## Key Concepts\n\n- **Zero-Version Interface Contracts (ZVIC):** Manages code compatibility without version numbers, relying on signature hashes and runtime checks. Contracts are verified at definition time and dynamically at runtime.\n\n## Who Should Use ZVIC?\n\n- Library authors who want to guarantee interface compatibility without versioning headaches.\n- Teams practicing hot-reload or rapid deployment of Python modules.\n- Anyone needing robust, runtime-checked API contracts for Python code.\n\n## Goals\n\n- Eliminate the need for semantic versioning in shared code\n- Enable safe, hot-reloadable modules\n- Provide runtime guarantees for interface compatibility\n- Facilitate rapid development and deployment cycles\n\n## Installation & requirements\n\n- Requirements:\n\t- Python 3.12+\n\n- Install (user):\n\n\t```sh\n\tpip install zvic\n\t```\n\n- Install (developer / editable):\n\n\t1. Create and activate a virtual environment\n\n\t\t - Windows (PowerShell):\n\n\t\t\t ```powershell\n\t\t\t py -3.12 -m venv .venv\n\t\t\t .\\.venv\\Scripts\\Activate.ps1\n\t\t\t ```\n\n\t\t - Unix / macOS:\n\n\t\t\t ```sh\n\t\t\t python3 -m venv .venv\n\t\t\t source .venv/bin/activate\n\t\t\t ```\n\n\t2. Install the package in editable mode:\n\n\t\t ```sh\n\t\t pip install -e .\n\t\t ```\n\n\tIf you want CrossHair support for semantic constraint analysis (optional), install the extra:\n\n\t```sh\n\tpip install .[crosshair]\n\t```\n\n### Quickstart\nFor a minimal programmatic check you can use the following snippet (run from the repo root):\n\n```py\nfrom pathlib import Path\nfrom zvic import load_module\nfrom zvic.compatibility import is_compatible\nfrom zvic.exception import SignatureIncompatible\n\na = load_module(Path('tests/stuff/mod_a.py'), 'mod_a')\nb = load_module(Path('tests/stuff/mod_b.py'), 'mod_b')\n\ntry:\n\tis_compatible(a.P2, b.P2)\n\tprint('compatible')\nexcept SignatureIncompatible as e:\n\tprint('incompatible:')\n\tprint(e.to_json())\n```\n\n\n## Canonicalization & Compatibility\n\nFunction signatures are canonicalized to ensure consistent interface identification and compatibility checks. See the [Canonicalization & Compatibility Spec](docs/specs/spec-04-Canonicalization-Compatibility.md) for details and compatibility rules.\n\n## Compatibility testing levels\nZVIC tests compatibility at multiple levels to give consumers high confidence before accepting a new module or version. The test strategy is deliberate and layered so that regressions are caught early and explained clearly.\n\n- Public interface presence\n\t- Modules are compared by their public attributes (respecting `__all__` when present). Any public attribute present in A but missing from B is reported as an incompatibility.\n\n- Callable-level checks (structural)\n\t- Callables (functions, methods, class `__call__`) are checked for signature compatibility. This covers parameter kinds (positional-only, positional-or-keyword, keyword-only), `*args`/`**kwargs`, default values, and parameter names where appropriate.\n\t- `are_params_compatible()` implements the scenario-based rules from the spec and raises structured errors when B cannot accept all calls that A accepts.\n\n- Type normalization and compatibility\n\t- A type-normalization layer canonicalizes runtime annotation types to a uniform schema.\n\t- `is_type_compatible()` implements rules such as: exact-type equality, allowed widening (derived\u2192base contravariant acceptance), disallowed narrowing (base\u2192derived), container invariance for invariants (e.g., `list[int]`), and ABC-aware acceptance.\n\n- Constraint checks (Annotated)\n- Constraint checking (Annotated)\n\t- ZVIC recognizes `typing.Annotated[T, constraint]` forms and will transform inline call-style annotations into `Annotated[...]` during module loading when necessary.\n\t- Constraint checking is best-effort: if the optional CrossHair analyser is installed, ZVIC will attempt a semantic verification (searching for counterexamples). If CrossHair is not available or cannot analyze a predicate, ZVIC falls back to deterministic heuristics (for example numeric/length comparisons) and ultimately to exact-match of the constraint expression.\n\n- Class and enum checks\n\t- Classes are compared for missing methods, and important special call sites such as `__init__` and `__call__` are compared recursively.\n\t- Enum compatibility ensures member presence and value stability (we require that names present in A also exist in B and that their underlying values remain equal), while allowing reordering or new additional members in B.\n\n- End-to-end tests\n\t- The test-suite includes unit tests that exercise canonicalization, parameter scenarios, type compatibility edge-cases, and small integration examples. See `tests/` for examples and `docs/specs/spec-08-Test-Plan.md` for the test plan.\n\n## How to run the test-suite\n\nFrom the repository root:\n\n```sh\npytest -q\n```\n\nRun a single test file (example):\n\n```sh\npytest tests/test_spec08_compatibility.py -q\n```\n\nOptional: run an individual test by name with `-k`.\n\n## Constraint checking and security - BEWARE MAGIC\nTake this example:\n\n\tdef foo(x: int(_ < 10)) -> int(_ < 10):\n\t\treturn x * 2\n\nNote that the `_ < 10` must be a valid Python expression (and thus is valid Python syntax, even though it looks weird!), but it is not evaluated in this context. With `from __future__ import annotations`, the whole annotation is treated as a string. ZVIC extracts this part and transforms it - first we append it to the docstring as pre/post conditions for crosshair to analyze \"statically\", second we transform the expression into a valid `assert` for runtime checking, if the interpreter is running in debug (not-optimized) mode.\n\nIf CrossHair is present, ZVIC will try to use it to search for counterexamples; if CrossHair is not present or cannot handle the predicate, ZVIC uses deterministic heuristics (numeric/length comparisons) and finally requires an exact expression match as a last resort.\n\n## Security note\nZVIC performs runtime annotation resolution and, in some code paths, evaluates constraint expressions. This can execute arbitrary code from the loaded module. ***Do not run ZVIC against untrusted code without an appropriate sandbox***. If you must inspect untrusted modules, consider running ZVIC in an isolated environment (container, VM, or restricted subprocess). Since ZVIC also makes use of eval() to check type compatibility in dynamic contexts, be aware that this can execute arbitrary code from the module being checked even if you don't make use of constraints - **exercise caution**.\n\n## Runtime requirements and packaging\n- Python: 3.12+\n- Install locally (editable):\n\n```sh\npip install -e .\n```\n\n## Release notes and changelog\nSee `CHANGELOG.md` for release history and the summary of specs implemented in each release.\n\n## Examples (from spec-08 tests)\n\nBelow are small, representative examples taken from the `spec-08` compatibility tests in `tests/stuff/` with the expected ZVIC behaviour.\n\n- Compatible example (P1): positional-only parameters, same required/total \u2014 compatible, different names\n\n```py\n# Module A\ndef P1(a, b, /):\n\tpass\n\n# Module B\ndef P1(x, y, /):\n\tpass\n\n# Expected: is_compatible(mod_a.P1, mod_b.P1) -> no exception (compatible)\n```\n\n- Incompatible example (P2): B adds a required parameter \u2014 incompatible\n\n```py\n# Module A\ndef P2(a, b, /):\n\tpass\n\n# Module B\ndef P2(x, y, z, /):\n\tpass\n\n# Expected: is_compatible(mod_a.P2, mod_b.P2) -> raises SignatureIncompatible\n# Typical diagnostic (ZVIC will raise `SignatureIncompatible` with context):\n# {\n# \"message\": \"B has more required parameters than A\",\n# \"context\": {\"A\": \"(a, b, /)\", \"B\": \"(x, y, z, /)\"},\n# \"error_id\": \"ZV1001\",\n# }\n```\n\n- Constraint narrowing example (C4): A permits values < 20, B restricts to < 10 \u2014 incompatible\n\n```py\n# Module A\ndef C4(a: int(_ < 20)):\n\tpass\n\n# Module B\ndef C4(a: int(_ < 10)):\n\tpass\n\n# Expected: is_compatible(mod_a.C4, mod_b.C4) -> raises SignatureIncompatible\n# Typical diagnostic message string produced by ZVIC:\n# \"Constraint mismatch for parameter a: _ < 20 vs _ < 10 (B is narrower and thus incompatible: some inputs that A accepts will not be accepted by B)\"\n```\n\n## Try the examples\n\nYou can run a small convenience script that loads the real `tests/stuff` modules and prints compatibility results for a few spec-08 scenarios.\n\nFrom the repository root (PowerShell example):\n\n```powershell\npy -3.12 examples/run_spec08_examples.py\n```\n\nOr, if your default python interpreter is Python >= 3.12 and on PATH:\n\n```sh\npy examples/run_spec08_examples.py\n```\n\nSample output (trimmed):\n\n--- Example: P1 ---\nResult: compatible (no exception)\n\n--- Example: P2 ---\nResult: incompatible \u2014 diagnostic:\n{\n\t\"error_id\": \"ZV1001\",\n\t\"type\": \"SignatureIncompatible\",\n\t\"severity\": \"error\",\n\t\"message\": \"B has more required parameters than A\",\n\t\"context\": {\"A\": \"(a, b, /)\", \"B\": \"(x, y, z, /)\", \"llm_hint\": \"...\"},\n\t...\n}\n\n--- Example: C4 ---\nResult: incompatible \u2014 diagnostic:\n{\n\t\"error_id\": \"ZV1001\",\n\t\"type\": \"SignatureIncompatible\",\n\t\"severity\": \"error\",\n\t\"message\": \"Constraint mismatch for parameter a: _ < 20 vs _ < 10 (B is narrower and thus incompatible: some inputs that A accepts will not be accepted by B)\",\n\t...\n}\n\n## Project status\n\nStability: Beta\n\n- Development status: actively developed and maintained. The test-suite runs locally and the repository currently has a comprehensive unit test suite, with all tests passing.\n- Test coverage: unit tests exercise canonicalization, compatibility scenarios, and edge-cases.\n- API stability: not guaranteed. Public APIs may change between releases as the project iterates on the specification and compatibility rules \u2014 please pin versions for production use and run the test-suite when upgrading.\n- Recommended use: evaluation, experimentation, and integration testing. For critical production use, perform an acceptance pass and pin a released version.\n- Contributing: contributions, issues, and PRs are welcome; see `CHANGELOG.md` and the `docs/specs/` for the current design decisions.\n\n## Project Structure\n- `README.md` - this document\n- `src/` - Main source code\n- `tests/` - Test suite (unit, integration, TDD, quick tests)\n- `docs/specs/` - Detailed specifications\n- `pyproject.toml` - Build and packaging configuration\n- `setup.py` - Minimal legacy packaging script\n- `CHANGELOG.md` - Release notes and change history\n- `examples/` - Example scripts and usage patterns\n\n## Further Reading\n\n- [Spec 01: Introduction](docs/specs/spec-01-Introduction.md)\n- [Spec 02: SDFP Principles](docs/specs/spec-02-SDFP-Principles.md)\n- [Spec 03: ZVIC Contracts](docs/specs/spec-03-ZVIC-Contracts.md)\n- [Spec 04: Canonicalization & Compatibility](docs/specs/spec-04-Canonicalization-Compatibility.md)\n\n## Versioning Scheme\n\nZVIC uses a CalVer versioning scheme: `YYYY.0W[.patchN/devN/rcN]`, where:\n- `YYYY` is the year\n- `0W` is the zero-padded ISO week number\n- Optional `.patchN`, `.devN`, `.rcN` for patches, dev, or release candidates\n\nFor example, `2025.26` corresponds to week 26 of 2025. This mirrors the structure of our Scrum logs (see `/docs/scrum/README.md`).\n\n# Office Hours\nYou can also contact me one-on-one! Check my [office hours](https://calendly.com/amogorkon/officehours) to set up a meeting :-)\n\nIf you have questions also feel free to use the github issues or the [ZVIC Discussions](https://github.com/amogorkon/ZVIC/discussions).\n\n\n***Enjoy!***\n",
"bugtrack_url": null,
"license": null,
"summary": "Zero-Version Interface Contracts (ZVIC) - signature-based compatibility for Python modules.",
"version": "2025.34",
"project_urls": null,
"split_keywords": [],
"urls": [
{
"comment_text": null,
"digests": {
"blake2b_256": "d02a4f76f16c6196169965358251f69c98f3efcc6971efc8ee685fac001b99f5",
"md5": "ffaf88e7d273a082fb78a570fada4a9c",
"sha256": "66c06caebb32c0cfc079f28a42d3af462f0b4394b3949cfcd2193573083dc992"
},
"downloads": -1,
"filename": "zvic-2025.34-py3-none-any.whl",
"has_sig": false,
"md5_digest": "ffaf88e7d273a082fb78a570fada4a9c",
"packagetype": "bdist_wheel",
"python_version": "py3",
"requires_python": ">=3.12",
"size": 30076,
"upload_time": "2025-08-20T15:25:02",
"upload_time_iso_8601": "2025-08-20T15:25:02.346878Z",
"url": "https://files.pythonhosted.org/packages/d0/2a/4f76f16c6196169965358251f69c98f3efcc6971efc8ee685fac001b99f5/zvic-2025.34-py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": null,
"digests": {
"blake2b_256": "4189c03ce32ddca1be8672332ceea0cdf53e237abfd1193cc37f9468f1943456",
"md5": "95713bf129dbd670ec11206461f3991b",
"sha256": "1533b9799005962793a79754b40f9dad6a5762161bfee6483d4d129a71c14173"
},
"downloads": -1,
"filename": "zvic-2025.34.tar.gz",
"has_sig": false,
"md5_digest": "95713bf129dbd670ec11206461f3991b",
"packagetype": "sdist",
"python_version": "source",
"requires_python": ">=3.12",
"size": 33377,
"upload_time": "2025-08-20T15:25:03",
"upload_time_iso_8601": "2025-08-20T15:25:03.702622Z",
"url": "https://files.pythonhosted.org/packages/41/89/c03ce32ddca1be8672332ceea0cdf53e237abfd1193cc37f9468f1943456/zvic-2025.34.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2025-08-20 15:25:03",
"github": false,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"lcname": "zvic"
}
