Skip to main content

plugmem

⚠️ Experimental. plugmem is mostly an AI-built experiment — written with the help of a small local model (Qwen3.6-35B-A3B-UD-Q4_K_XL.gguf) and various Claude models, in roughly equal measure. Expect non-professional design choices, rough edges, broken behavior, or mistakes. Use it at your own risk.

An embeddable bitemporal memory database for local-first applications and agents, embedded in your Python process. It stores short facts and answers a query with ranked facts and edges plus an optional bounded rendered block.

File-backed on disk, no server, no daemon. It links into your process the way SQLite does: the engine is plugmem-host compiled to a CPython extension module through PyO3, so the data lives in mapped files rather than in the interpreter's heap. Every call releases the GIL for the duration of the work.

No embedding model is required. Three of the four retrieval sources — text, graph and time — need nothing but the database. An embedder is optional and adds the fourth; see Do you need an embedder? for what changes when you add one and what you give up without it.

Contents: Install · Quick start · Do you need an embedder? · What it stores · Two clocks · How recall works · API · Errors · Configuration · Threads and the GIL · Typing · Many memories · What it is not for

Install

$ pip install plugmem

Prebuilt wheels cover Linux, macOS and Windows on x86-64 and arm64. One wheel per platform serves every CPython from 3.10 on — it is built against the stable ABI, which does not change between versions — plus a separate wheel for the free-threaded 3.14t build, which has an ABI of its own. No toolchain, no build step.

Quick start

import plugmem

db = plugmem.Plugmem.open("agent.plugmem")

db.remember("the user prefers tokio", entity="user", tags=["pref"])
db.remember("the release ships on friday", entity="release")

res = db.recall("tokio", k=5)
print(res.rendered)

db.close()
## memory
- [f0] user: the user prefers tokio (2026-08; active) #pref

Plugmem is also a context manager, which is the usual way to write it:

with plugmem.Plugmem.open("agent.plugmem") as db:
    db.remember("the deploy target is fly.io", entity="release")

open is a static method rather than a constructor because it takes the file's exclusive lock, replays the journal and maps the snapshot — work proportional to what is on disk, and worth naming rather than hiding behind Plugmem(...).

Do you need an embedder?

No, and it is worth being precise about what that costs, because the answer decides how you should write your queries.

Without one, three sources answer: BM25 over the text, the entity graph, and time. That is a working memory with no model, no API key, no network call and no per-query cost. What you lose is matching by meaning: BM25 needs shared words, so the query above finds the fact because both say "tokio". Ask it the way a person would —

db.recall("which runtime?", k=5)   # → no facts: no word in common

— and you get nothing back, because "runtime" appears nowhere in "the user prefers tokio". Anchor on an entity (entities=["user"]) or use the words the fact uses, and it answers.

With one, a fourth source runs: each fact and each query is embedded, and cosine similarity finds the fact whose meaning is close even when no word matches. "which runtime?" then reaches "the user prefers tokio". The cost is a provider round trip per write and per text query, an API key, and a dim that is fixed for the life of the database.

You can also skip the provider and pass vectors yourself — see Bringing your own embedding — which is the route for a local model or one that is not an OpenAI-shaped HTTP endpoint.

Sensible default: start without one. Tag and anchor your facts, see whether lexical recall is enough for your queries, and add an embedder when you catch yourself wishing a query had understood a synonym.

What it stores

A fact is one short statement plus the things that make it findable and datable:

db.remember(
    "the user prefers tokio",
    entity="user",                       # the subject
    tags=["pref", "runtime"],            # filters
    links=[("works_on", "plugmem")],     # typed edges from the subject
    metadata={"src": "chat-2026-08-05"}, # opaque to the engine
    valid_from=1_767_225_600_000,        # when it became true (unix ms)
)

metadata is a string-to-string map the engine never interprets. It is where a URI to the real payload goes, or a mime type, or a key in your own system — the fact stays short and searchable while the bulk stays wherever you keep bulk.

remember returns the new id and any live facts that look like duplicates or contradictions:

out = db.remember("the user prefers async-std", entity="user")
for hint in out.similar:
    print(hint.id, hint.score, hint.reason)   # 0 0.87 LexicalOverlap

The engine never merges on its own. You decide: revise if it changed, forget if it was wrong, or nothing if both are true at once.

Two clocks

This is what separates plugmem from a store that overwrites. Every fact carries two independent intervals:

  • recorded_at — when this memory learned it. Immutable.
  • valid_from / valid_to — when the statement was true in the world.

revise closes the old interval instead of deleting the old row:

JAN = 1_767_225_600_000   # 2026-01-01
JUL = 1_782_864_000_000   # 2026-07-01

berlin = db.remember("the user lives in berlin", entity="user", valid_from=JAN)
db.revise(berlin.id, "the user lives in lisbon", entity="user", valid_from=JUL)

db.recall("lives", entities=["user"])
# → [the user lives in lisbon]

db.recall("lives", entities=["user"], closed=True)
# → [the user lives in berlin, the user lives in lisbon]

The Berlin fact is still there, with valid_to now set to JUL — the instant its successor took over. Nothing was overwritten, so "where did the user live in March" remains answerable.

as_of asks the bitemporal question, and it filters on both axes:

db.recall("lives", entities=["user"], as_of=FEBRUARY)
# → []

Empty, and that is the correct answer rather than a bug. Both facts were recorded today, so as of February this memory did not know either of them. A memory that answered would be claiming knowledge it did not have. Ask as of an instant the memory had already reached and you get whatever was true then.

How recall works

Four sources run and are fused with reciprocal-rank fusion, then a recency boost is applied. Tags filter; they are not a source.

Source What it matches Needs an embedder
lexical BM25 over the fact text no
graph facts reachable from the anchors in entities no
time facts inside the range window no
vector cosine over embeddings yes
res = db.recall(
    "who owns the deploy",
    tags=["ops"],                  # a filter, not a source
    entities=["release"],          # graph anchors
    range=(FROM_MS, TO_MS),        # window over recorded_at
    k=8,                           # facts to return
    token_budget=512,              # size of `rendered`
    graph_depth=2,                 # hops from the anchors, this call only
)

for fact in res.facts:
    print(fact.id, fact.score, fact.sources)
for edge in res.edges:
    print(edge.src, edge.rel, edge.dst)
print(res.rendered)                # the bounded block
print(res.truncated)               # True if something was left out

res.facts and res.edges are the structured answer; res.rendered is a convenience for callers that want a block of text under a token budget. Neither is more real than the other.

graph_depth is per call because how wide a net to cast belongs to the question: "what is this person's stated preference" wants fewer hops than "what is known around this person". There is no ceiling — the walk is bounded by its own entity and edge caps.

API

Everything is synchronous. See Threads and the GIL for why that is the right shape and not a limitation.

Verb Does
Plugmem.open(path=None, *, dim=None, read_only=False, config=None) open or create; resolves PLUGMEM_DB, then [database].path, then the platform data path
remember(text, *, entity, tags, links, metadata, valid_from, vector) store one fact
remember_many(facts) store a batch — one journal write, one embedding round trip
revise(id, text, ...) close a fact's interval and record the successor
recall(query=None, *, tags, entities, as_of, range, k, closed, token_budget, ef, graph_depth, vector) the ranked answer
forget(id) tombstone a fact; maintain purges it later
link(src, rel, dst, *, provenance) / unlink(src, rel, dst) open or close a typed edge
get(id) / tags_of(id) / stats() one fact's card, its tags, engine counters
export() / export_page(cursor) / export_edges(on_batch) dump facts, dump them in pages, stream edges
verify() / scrub(budget=None) logical check; byte-level check
maintain(mode="auto") / checkpoint() housekeeping; publish a snapshot
generation() / refresh() read-only handles: which snapshot, and move to the newest
config_warnings() / path() / close() config typos, the resolved file, release it

Module level: version(), about(), settings_help(), skill(), skill_full(), skill_version(), recover(src, dst), and the export_pages(db) generator.

Bringing your own embedding

Pass vector and nothing is sent to a provider — it replaces the embedder for that call. This is the route for a local model, or one that is not an OpenAI-shaped HTTP endpoint:

db = plugmem.Plugmem.open("agent.plugmem", dim=384)
db.remember("the user prefers tokio", entity="user", vector=my_model.encode(text))
db.recall(vector=my_model.encode("which runtime?"), k=5)

The length must equal the configured dim, which is fixed when the database is created.

Backing up: facts are only half of it

A fact names its own tags and metadata, but an edge is a statement between two entities and outlives any single fact. A complete dump is both streams:

facts = []
for page in plugmem.export_pages(db):      # bounded pages, not one big list
    facts.extend(page.facts)

edges = []
db.export_edges(edges.extend)              # called with a list at a time

export_edges hands over batches rather than one edge per call, because each call has to reacquire the interpreter; the walk itself runs with the GIL released. It returns the total.

Checking a file has not rotted

verify() asks whether the indexes agree with the facts. scrub() asks whether the bytes on disk are the bytes that were written — it recomputes the stored checksums, which is what catches a flipped bit that the structure happily accepts.

with db.scrub() as scan:
    for progress in scan:
        print(f"{progress.done_bytes}/{progress.total_bytes}")

It is paced by you rather than run to completion, so it is affordable on a live database. Holding the object holds a lock on the snapshot generation it is scanning, so the writer cannot recycle that file underneath it — finish the scan or close it, which the with block does for you.

Repairing a damaged file

report = plugmem.recover("damaged.plugmem", "clean.plugmem")
print(report.kept, report.dropped_text, report.dropped_vector, report.dropped_metadata)

It reads the source fact by fact, writes what survives to a new file, and reports what it had to drop. The source is left untouched as evidence. This is not a repair for structural damage: a snapshot that will not parse cannot be walked, and that case is a restore from backup.

The one thing the Rust library has and this does not

import is not an engine verb — JSONL is a format the CLI defines. If you need it, remember_many plus link is the whole of it, in a dozen lines of Python you can shape to your own file.

Errors

Every failure this binding decides raises a subclass of PlugmemError carrying a stable code. The codes are the same strings the Node binding puts on a thrown Error, so cross-language documentation stays one table.

try:
    db = plugmem.Plugmem.open("agent.plugmem")
except plugmem.LockedError as e:
    print(e.code)          # PLUGMEM_LOCKED — another process holds the writer
Class code Means
LockedError PLUGMEM_LOCKED another process holds the writer lock
NeedsCheckpointError PLUGMEM_NEEDS_CHECKPOINT read_only on a database nobody has checkpointed
ConfigError PLUGMEM_CONFIG the config.toml could not be read or is invalid
OpenError PLUGMEM_OPEN any other failure to open
InvalidArgError PLUGMEM_INVALID_ARG an argument refused before it reached the engine
InvalidNameError PLUGMEM_INVALID_NAME not a usable memory name
ClosedError PLUGMEM_CLOSED close() was already called
ReadOnlyError PLUGMEM_READ_ONLY a write verb on a read-only handle
WriterOnlyError PLUGMEM_WRITER_ONLY generation/refresh on a writer
BusyError PLUGMEM_BUSY another operation holds this handle
EngineError PLUGMEM_ENGINE the engine failed; the message is its own

Configuration and embeddings

Without a config, plugmem answers from text, tags, the graph and time. Add an [embedder] section and remember/recall also embed, giving the vector source something to work with — see Do you need an embedder? for the trade.

The file is resolved the same way on every surface — CLI, MCP server, Node and Python: an explicit path, then $PLUGMEM_CONFIG, then $XDG_CONFIG_HOME/plugmem/config.toml.

# plugmem.toml
[database]
path = "~/.local/share/plugmem/agent.plugmem"

[engine]
dim = 1536

# Optional. Delete this section and everything still works, minus the vector
# source.
[embedder]
kind = "openai"
url = "https://api.openai.com/v1/embeddings"
model = "text-embedding-3-small"
api_key_env = "OPENAI_API_KEY"

[recall]
w_bm25 = 1.0        # weight of the lexical source
w_vec = 1.0         # weight of the vector source
w_graph = 0.7       # weight of the graph source
half_life_days = 30 # how fast the recency boost decays
graph_depth = 2     # default hops, overridable per call
db = plugmem.Plugmem.open("agent.plugmem", config="plugmem.toml")

plugmem.settings_help() returns the whole catalogue — every section, key, type, default and what it does — without opening anything.

When a key is misspelled

A typo in a key used to change nothing, silently. Now it is reported:

db = plugmem.Plugmem.open("agent.plugmem", config="plugmem.toml")
for warning in db.config_warnings():
    print(warning)
# [recall] unknown key `w_vector` — did you mean `w_vec`?

It is a value rather than a printed warning because a library has nowhere sensible to print. Read it once after opening and log it your own way.

Threads and the GIL

Every verb releases the GIL for the duration of the work. While a recall is inside the engine no bytecode executes on that thread's behalf, so the interpreter is free and other threads run.

That is why the API is synchronous and has no async def. The thing an async API would buy — not blocking everything else — is already true:

import asyncio

res = await asyncio.to_thread(db.recall, "tokio", k=5)

to_thread works correctly here because the GIL is released. An async layer would add a runtime and a scheduler to reach the same place.

A handle is safe to share across threads. Reads genuinely overlap; refresh and close take the handle exclusively, so a reader never observes it half-swapped.

from concurrent.futures import ThreadPoolExecutor

with ThreadPoolExecutor(max_workers=8) as pool:
    results = list(pool.map(lambda q: db.recall(q, k=4), queries))

Writes serialize inside the engine, which is a property of the engine and not of this binding — one writer per file is the design. Embedding happens outside that lock, so several remember calls do reach the provider at once.

Reading while another process writes

reader = plugmem.Plugmem.open("agent.plugmem", read_only=True)
print(reader.generation())      # which published snapshot this is
if reader.refresh():            # move to the newest one
    print("moved to", reader.generation())

A read-only handle maps a published snapshot without taking the writer's lock, so it coexists with a live writer in another process. It needs the database to have been checkpointed at least once; otherwise NeedsCheckpointError.

Typing

The package ships py.typed and generated stubs, so an editor completes the API and a type checker checks it. The stubs are generated from the same macros the binding is written with and gated in CI against the Rust surface, so they cannot describe a method that does not exist.

res: plugmem.RecallResult = db.recall("tokio", k=5)
first: plugmem.RecalledFact = res.facts[0]

Results are frozen: they are what the engine said, and mutating a copy of that is never what anyone means.

Many memories in one directory

Optional. If you want one memory, point Plugmem.open at a file and skip this.

For a process serving many independent memories — one per conversation, per tenant, per project — address them by name instead:

ws = plugmem.Workspace("~/bot-data")

db = ws.open("conversation-42")            # first use creates it
db.remember("the user prefers dark mode", entity="user")

ws.describe("conversation-42", "support thread about billing", owner="ann")
for entry in ws.find("billing"):
    print(entry.db, entry.description)

A name ([a-z0-9][a-z0-9_-]*) is not a path and cannot become one, so it resolves to exactly one database inside the directory. describe is what makes find useful when the caller does not know the name; owner is recorded as an edge, so find("ann") returns what Ann owns even though no description mentions her.

The workspace keeps a bounded pool of open memories and closes the least recently used to make room. close_idle() closes those idle past the configured timeout, which matters because an open memory holds that database's exclusive lock.

What it is not for

plugmem is for local-first application and agent memory: one process, one local database, no service to operate. Its design centre is around 100 000 active facts on one machine, and the benchmarks track 1M-operation profiles to show how the same engine behaves under heavier local load.

It is not a vector database and not built for multi-million vector workloads, cluster sharding, multi-tenant serving or managed nearest-neighbour search. For those, use a dedicated system — Qdrant, Milvus, Weaviate, Pinecone or pgvector.

Other ways in

The same engine ships five ways. This package is the Python one.

You are Use
writing Python this package
writing JavaScript / TypeScript for Node plugmem on npm
writing Rust plugmem-host — the engine in your process
an agent, or another language plugmem-mcp — a stdio JSON-RPC sidecar
a person at a terminal plugmem-cli

Working with an LLM agent? There is a companion skill describing the remember/recall loop, the contradiction workflow and the verbs. This package ships it: skill() returns the text and skill_version() the version it was written against.

License

MIT. Source: https://github.com/m62624/plugmem

Download files

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

Source Distributions

No source distribution files available for this release.See tutorial on generating distribution archives.

Built Distributions

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

plugmem-0.7.0-cp314-cp314t-win_arm64.whl (3.9 MB view details)

Uploaded CPython 3.14tWindows ARM64

plugmem-0.7.0-cp314-cp314t-win_amd64.whl (3.9 MB view details)

Uploaded CPython 3.14tWindows x86-64

plugmem-0.7.0-cp314-cp314t-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (4.3 MB view details)

Uploaded CPython 3.14tmanylinux: glibc 2.17+ x86-64

plugmem-0.7.0-cp314-cp314t-manylinux_2_17_aarch64.manylinux2014_aarch64.whl (4.4 MB view details)

Uploaded CPython 3.14tmanylinux: glibc 2.17+ ARM64

plugmem-0.7.0-cp314-cp314t-macosx_11_0_arm64.whl (4.1 MB view details)

Uploaded CPython 3.14tmacOS 11.0+ ARM64

plugmem-0.7.0-cp314-cp314t-macosx_10_12_x86_64.whl (4.2 MB view details)

Uploaded CPython 3.14tmacOS 10.12+ x86-64

plugmem-0.7.0-cp310-abi3-win_arm64.whl (3.9 MB view details)

Uploaded CPython 3.10+Windows ARM64

plugmem-0.7.0-cp310-abi3-win_amd64.whl (3.9 MB view details)

Uploaded CPython 3.10+Windows x86-64

plugmem-0.7.0-cp310-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (4.4 MB view details)

Uploaded CPython 3.10+manylinux: glibc 2.17+ x86-64

plugmem-0.7.0-cp310-abi3-manylinux_2_17_aarch64.manylinux2014_aarch64.whl (4.4 MB view details)

Uploaded CPython 3.10+manylinux: glibc 2.17+ ARM64

plugmem-0.7.0-cp310-abi3-macosx_11_0_arm64.whl (4.1 MB view details)

Uploaded CPython 3.10+macOS 11.0+ ARM64

plugmem-0.7.0-cp310-abi3-macosx_10_12_x86_64.whl (4.2 MB view details)

Uploaded CPython 3.10+macOS 10.12+ x86-64

File details

Details for the file plugmem-0.7.0-cp314-cp314t-win_arm64.whl.

File metadata

  • Download URL: plugmem-0.7.0-cp314-cp314t-win_arm64.whl
  • Upload date:
  • Size: 3.9 MB
  • Tags: CPython 3.14t, Windows ARM64
  • Uploaded using Trusted Publishing? Yes
  • Uploaded via: twine/7.0.0 CPython/3.13.14

File hashes

Hashes for plugmem-0.7.0-cp314-cp314t-win_arm64.whl
Algorithm Hash digest
SHA256 b112ecd4a1a433dbaa9d9a207445a6b9f09853da24664b00c5f5eeab50295bfc
MD5 df3841b82873b824f818e9e42c4208c0
BLAKE2b-256 f583a70371ef43293c79dea9466ef60aa95191d6f299d54bb38997cba7e2aadc

See more details on using hashes here.

Provenance

The following attestation bundles were made for plugmem-0.7.0-cp314-cp314t-win_arm64.whl:

Publisher: release.yml on m62624/plugmem

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

File details

Details for the file plugmem-0.7.0-cp314-cp314t-win_amd64.whl.

File metadata

  • Download URL: plugmem-0.7.0-cp314-cp314t-win_amd64.whl
  • Upload date:
  • Size: 3.9 MB
  • Tags: CPython 3.14t, Windows x86-64
  • Uploaded using Trusted Publishing? Yes
  • Uploaded via: twine/7.0.0 CPython/3.13.14

File hashes

Hashes for plugmem-0.7.0-cp314-cp314t-win_amd64.whl
Algorithm Hash digest
SHA256 f91f64279d22786ac18a6e573972ae01e717bc5e2d5dd5d8461e0284cef356ab
MD5 9556b61dfec70e2ae413dc81cd282f3e
BLAKE2b-256 4de42d7bf0551c3496d37036217047caa67966b522408dd809cc2c5b4e5e7aed

See more details on using hashes here.

Provenance

The following attestation bundles were made for plugmem-0.7.0-cp314-cp314t-win_amd64.whl:

Publisher: release.yml on m62624/plugmem

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

File details

Details for the file plugmem-0.7.0-cp314-cp314t-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.

File metadata

File hashes

Hashes for plugmem-0.7.0-cp314-cp314t-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
Algorithm Hash digest
SHA256 a1232903e321ae6a5fbf516ca16f91e9a37b5b5186c7bf2afb99ab124111d4c7
MD5 2ef200d101815b5994cbbe5deaa5292f
BLAKE2b-256 d6cdd884ce2e07f9d3aae01af04be17798ddacceb11192b36e482dcd4252103e

See more details on using hashes here.

Provenance

The following attestation bundles were made for plugmem-0.7.0-cp314-cp314t-manylinux_2_17_x86_64.manylinux2014_x86_64.whl:

Publisher: release.yml on m62624/plugmem

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

File details

Details for the file plugmem-0.7.0-cp314-cp314t-manylinux_2_17_aarch64.manylinux2014_aarch64.whl.

File metadata

File hashes

Hashes for plugmem-0.7.0-cp314-cp314t-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
Algorithm Hash digest
SHA256 a48d2dfc2fa8edd1a4a2284a03f72ba3341a4d98739e1a16101b8fb2d99118ad
MD5 327860de4690d29730ea369e8cf230c1
BLAKE2b-256 7fe2244a02f19a1f737dd8a6833674912d619aafbaf7c058e3f11a5cac81a59f

See more details on using hashes here.

Provenance

The following attestation bundles were made for plugmem-0.7.0-cp314-cp314t-manylinux_2_17_aarch64.manylinux2014_aarch64.whl:

Publisher: release.yml on m62624/plugmem

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

File details

Details for the file plugmem-0.7.0-cp314-cp314t-macosx_11_0_arm64.whl.

File metadata

File hashes

Hashes for plugmem-0.7.0-cp314-cp314t-macosx_11_0_arm64.whl
Algorithm Hash digest
SHA256 d042180229b7b5b70f8a8719c9fab723ddd3f6c6b3c2629d80dd9a1870fd7511
MD5 e04fca12a41db6e7483b8acebdb51d78
BLAKE2b-256 3f34b72a58408704ce60f7b340dfd3c648a804286f664806d8cbf9322b8e3fb9

See more details on using hashes here.

Provenance

The following attestation bundles were made for plugmem-0.7.0-cp314-cp314t-macosx_11_0_arm64.whl:

Publisher: release.yml on m62624/plugmem

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

File details

Details for the file plugmem-0.7.0-cp314-cp314t-macosx_10_12_x86_64.whl.

File metadata

File hashes

Hashes for plugmem-0.7.0-cp314-cp314t-macosx_10_12_x86_64.whl
Algorithm Hash digest
SHA256 0eeb811fbd6df954572ed232e7b50b312d743776075030615bab5e0b776619db
MD5 c89a1db5255090c3f829db71c7530074
BLAKE2b-256 0779132f05423d856ac647829a0c4d15a953a8d3307188a63d1338e498a9eb1e

See more details on using hashes here.

Provenance

The following attestation bundles were made for plugmem-0.7.0-cp314-cp314t-macosx_10_12_x86_64.whl:

Publisher: release.yml on m62624/plugmem

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

File details

Details for the file plugmem-0.7.0-cp310-abi3-win_arm64.whl.

File metadata

  • Download URL: plugmem-0.7.0-cp310-abi3-win_arm64.whl
  • Upload date:
  • Size: 3.9 MB
  • Tags: CPython 3.10+, Windows ARM64
  • Uploaded using Trusted Publishing? Yes
  • Uploaded via: twine/7.0.0 CPython/3.13.14

File hashes

Hashes for plugmem-0.7.0-cp310-abi3-win_arm64.whl
Algorithm Hash digest
SHA256 fe01b68cc602080ec9eb695e6ea5b69bfbe877ed00bac9529b625a6be6737d1a
MD5 aa5b4ad88751e072edfa645cbc249c1e
BLAKE2b-256 82c3c4ed6613809d9208251200192ff84033ec34eb086d81a7bf83cf02d258df

See more details on using hashes here.

Provenance

The following attestation bundles were made for plugmem-0.7.0-cp310-abi3-win_arm64.whl:

Publisher: release.yml on m62624/plugmem

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

File details

Details for the file plugmem-0.7.0-cp310-abi3-win_amd64.whl.

File metadata

  • Download URL: plugmem-0.7.0-cp310-abi3-win_amd64.whl
  • Upload date:
  • Size: 3.9 MB
  • Tags: CPython 3.10+, Windows x86-64
  • Uploaded using Trusted Publishing? Yes
  • Uploaded via: twine/7.0.0 CPython/3.13.14

File hashes

Hashes for plugmem-0.7.0-cp310-abi3-win_amd64.whl
Algorithm Hash digest
SHA256 0148d320d7a44b2011b845cdca7d006f993ed904ce77c34b7d6dff7b4bddd27c
MD5 89afea7e8513ef5cd64fa4a9fecec859
BLAKE2b-256 70d030608892ddca30aa719097a3ef2d7a96ad8e2d7325116348b749fcd19fb3

See more details on using hashes here.

Provenance

The following attestation bundles were made for plugmem-0.7.0-cp310-abi3-win_amd64.whl:

Publisher: release.yml on m62624/plugmem

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

File details

Details for the file plugmem-0.7.0-cp310-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.

File metadata

File hashes

Hashes for plugmem-0.7.0-cp310-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
Algorithm Hash digest
SHA256 17afca0a00fb9bdd30b0d704ac4bd6c3a672031ccf3fdce65476b97579a1cb0e
MD5 2ee6af54b1a6f71fe497ed38dad54859
BLAKE2b-256 da73a4e9faeb8107ab74eee51cc5c6f77e66ee2f24086e53a311dc691877c6d1

See more details on using hashes here.

Provenance

The following attestation bundles were made for plugmem-0.7.0-cp310-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64.whl:

Publisher: release.yml on m62624/plugmem

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

File details

Details for the file plugmem-0.7.0-cp310-abi3-manylinux_2_17_aarch64.manylinux2014_aarch64.whl.

File metadata

File hashes

Hashes for plugmem-0.7.0-cp310-abi3-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
Algorithm Hash digest
SHA256 5a4db1cbc58f3096c8a72e4d0c5156961fbd76b181a06ba5ccb65bfa6e319f34
MD5 f52e69e02d1f09252e7a07bb19f99e64
BLAKE2b-256 194ec75b347402b6907845b6afffce105bf397e3b077a8238c9ab17fd59b09ee

See more details on using hashes here.

Provenance

The following attestation bundles were made for plugmem-0.7.0-cp310-abi3-manylinux_2_17_aarch64.manylinux2014_aarch64.whl:

Publisher: release.yml on m62624/plugmem

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

File details

Details for the file plugmem-0.7.0-cp310-abi3-macosx_11_0_arm64.whl.

File metadata

File hashes

Hashes for plugmem-0.7.0-cp310-abi3-macosx_11_0_arm64.whl
Algorithm Hash digest
SHA256 3e47fdcb478bc18126b2607535bbafa14d52ca1c00cb61721a31915f11052e4a
MD5 222ed3deca9fe78cc2338c4dabbbda64
BLAKE2b-256 0b7d63d812e3c9de7572c7c06a3fde5af5026425f49f088ce7abed9afc83a3b2

See more details on using hashes here.

Provenance

The following attestation bundles were made for plugmem-0.7.0-cp310-abi3-macosx_11_0_arm64.whl:

Publisher: release.yml on m62624/plugmem

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

File details

Details for the file plugmem-0.7.0-cp310-abi3-macosx_10_12_x86_64.whl.

File metadata

File hashes

Hashes for plugmem-0.7.0-cp310-abi3-macosx_10_12_x86_64.whl
Algorithm Hash digest
SHA256 33af0e8dbe6edb8e9fc448e9d16786a11e58a44879413bb2c1033d8ec7ba39b1
MD5 525a5381139e0ad2eed668de8981ec2a
BLAKE2b-256 2039cac29609a4d8fecd5853ad69cb3b1a30eabb358d7758a3211b4c476a7f14

See more details on using hashes here.

Provenance

The following attestation bundles were made for plugmem-0.7.0-cp310-abi3-macosx_10_12_x86_64.whl:

Publisher: release.yml on m62624/plugmem

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