tract-api

Crates.iotract-api
lib.rstract-api
version
sourcesrc
created_at2023-08-29 12:39:20.742011
updated_at2024-12-05 10:44:09.08507
descriptionTiny, no-nonsense, self contained, TensorFlow and ONNX inference
homepage
repositoryhttps://github.com/sonos/tract
max_upload_size
id958054
Cargo.toml error:TOML parse error at line 25, column 1 | 25 | autolib = false | ^^^^^^^ unknown field `autolib`, expected one of `name`, `version`, `edition`, `authors`, `description`, `readme`, `license`, `repository`, `homepage`, `documentation`, `build`, `resolver`, `links`, `default-run`, `default_dash_run`, `rust-version`, `rust_dash_version`, `rust_version`, `license-file`, `license_dash_file`, `license_file`, `licenseFile`, `license_capital_file`, `forced-target`, `forced_dash_target`, `autobins`, `autotests`, `autoexamples`, `autobenches`, `publish`, `metadata`, `keywords`, `categories`, `exclude`, `include`
size0
Mathieu Poumeyrol (kali)

documentation

README

tract 1.0 public API (draft)

TLDR

A regular Rust project should include tract-rs only.

Scope

These crates are meant to represent a public API for tract for integration in "simple" use case. We commit on Semver stability on these crates interface. The other crates are considered internal and their interface can change any time.

The public API scope is limited to model-level manipulation, no access to individual model graph nodes and operators is allowed.

Crates

  • interface definition: tract-api in tract/api
  • rust implementation over tract internal crates: tract-rs in tract/api/rs
  • tract as a C-friendly dynamic library: tract-ffi in tract/api/ffi
  • rust client over tract-ffi (use tract as a shared library): tract-proxy in tract/api/proxy. It implements tract-api, so is source-swapable with tract-rs.
  • python client: in tract/api/py
Commit count: 6847

cargo fmt