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 the platform config directory — $XDG_CONFIG_HOME/plugmem/config.toml on Linux, ~/Library/Application Support/plugmem/config.toml on macOS, %APPDATA%\plugmem\config\config.toml on Windows.

# 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 Distribution

plugmem-0.7.1.tar.gz (589.3 kB view details)

Uploaded Source

Built Distributions

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

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

Uploaded CPython 3.14tWindows ARM64

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

Uploaded CPython 3.14tWindows x86-64

plugmem-0.7.1-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.1-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.1-cp314-cp314t-macosx_11_0_arm64.whl (4.1 MB view details)

Uploaded CPython 3.14tmacOS 11.0+ ARM64

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

Uploaded CPython 3.14tmacOS 10.12+ x86-64

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

Uploaded CPython 3.10+Windows ARM64

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

Uploaded CPython 3.10+Windows x86-64

plugmem-0.7.1-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.1-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.1-cp310-abi3-macosx_11_0_arm64.whl (4.1 MB view details)

Uploaded CPython 3.10+macOS 11.0+ ARM64

plugmem-0.7.1-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.1.tar.gz.

File metadata

  • Download URL: plugmem-0.7.1.tar.gz
  • Upload date:
  • Size: 589.3 kB
  • Tags: Source
  • Uploaded using Trusted Publishing? Yes
  • Uploaded via: twine/7.0.0 CPython/3.13.14

File hashes

Hashes for plugmem-0.7.1.tar.gz
Algorithm Hash digest
SHA256 d8b059b983b5e1130a5123ac77cf83302665b92fc04ec6fa5af8ddbfc3385800
MD5 eaae2072bb5cbfe4412919f7f37ab4dd
BLAKE2b-256 7925491e82486d778bde5da0685658aec56ccd8cdf83ad1df1f41ade03aea58e

See more details on using hashes here.

Provenance

The following attestation bundles were made for plugmem-0.7.1.tar.gz:

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.1-cp314-cp314t-win_arm64.whl.

File metadata

  • Download URL: plugmem-0.7.1-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.1-cp314-cp314t-win_arm64.whl
Algorithm Hash digest
SHA256 74a9e9cba201fb8b974267f4743a9da30b8a2cc8830c5e167d5fd828d9deb7e4
MD5 f6476894c100aebd438e946eb2cb8258
BLAKE2b-256 bf72f3598bf37853e26c51b40f3f9c949cd651f69a7383652bef8509657d9372

See more details on using hashes here.

Provenance

The following attestation bundles were made for plugmem-0.7.1-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.1-cp314-cp314t-win_amd64.whl.

File metadata

  • Download URL: plugmem-0.7.1-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.1-cp314-cp314t-win_amd64.whl
Algorithm Hash digest
SHA256 ad337e5b5ccd864583cb4665589c85f8c5d9077e7c1d6d198b8d0ff17444c37a
MD5 70754717f24505728ccf97ff29948e26
BLAKE2b-256 8e232d1ab52d72a2f8b27278f1dae992f5df1383abb9775faa02d113ea23ac41

See more details on using hashes here.

Provenance

The following attestation bundles were made for plugmem-0.7.1-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.1-cp314-cp314t-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.

File metadata

File hashes

Hashes for plugmem-0.7.1-cp314-cp314t-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
Algorithm Hash digest
SHA256 08cd11f9693750ac906fb0a0b85f9012f0e7ff4529e19ae3885f8643fae4d9ad
MD5 2db9f9d5bff7ae7494faa08b3ad94f7c
BLAKE2b-256 3ef3cf4b5393c4bcb8064aa51c0aee6e3cd59b5cac96b59bc966083cd01d0db7

See more details on using hashes here.

Provenance

The following attestation bundles were made for plugmem-0.7.1-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.1-cp314-cp314t-manylinux_2_17_aarch64.manylinux2014_aarch64.whl.

File metadata

File hashes

Hashes for plugmem-0.7.1-cp314-cp314t-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
Algorithm Hash digest
SHA256 4f184babf56d3b172b18acef5397d8530ccb697d436836aafea2ed622cee5ceb
MD5 d131f286ebaabb43a59d9ab6b145bc81
BLAKE2b-256 1c9e777654a9d073e9c06c21db811b5f692da76bad742ad1826b81b89cf1a9c0

See more details on using hashes here.

Provenance

The following attestation bundles were made for plugmem-0.7.1-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.1-cp314-cp314t-macosx_11_0_arm64.whl.

File metadata

File hashes

Hashes for plugmem-0.7.1-cp314-cp314t-macosx_11_0_arm64.whl
Algorithm Hash digest
SHA256 e64f096574c93b9b8e65d17c616b8a79adb6347311d4dc9f4527ca2c0b3a9184
MD5 aec98eea0bc284912480a1448645e597
BLAKE2b-256 68e0174ce0cbfb7a679148304a25e31d45e586f29f592d1b96c488a6b0642cc4

See more details on using hashes here.

Provenance

The following attestation bundles were made for plugmem-0.7.1-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.1-cp314-cp314t-macosx_10_12_x86_64.whl.

File metadata

File hashes

Hashes for plugmem-0.7.1-cp314-cp314t-macosx_10_12_x86_64.whl
Algorithm Hash digest
SHA256 185c177b83a51337ba8a3105489b90e2a5a49e1e2f9ecb67e8055f4c06578b53
MD5 897be801bb1a6c488cc3d94925e62aec
BLAKE2b-256 52dc4658296300eb71f03c60c5a1d307540b71d2fa2624b710edc332fe321063

See more details on using hashes here.

Provenance

The following attestation bundles were made for plugmem-0.7.1-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.1-cp310-abi3-win_arm64.whl.

File metadata

  • Download URL: plugmem-0.7.1-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.1-cp310-abi3-win_arm64.whl
Algorithm Hash digest
SHA256 d611e54c7d40a80b330086941660e0956d26ac817e518171bfe92f2b746c393f
MD5 4e3e5fde992f5040f21b59e94fb26322
BLAKE2b-256 4bc24f235881296f312a5c167d41a7ef4cc0c31498ae48c7bd3f74ed1eba0ccb

See more details on using hashes here.

Provenance

The following attestation bundles were made for plugmem-0.7.1-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.1-cp310-abi3-win_amd64.whl.

File metadata

  • Download URL: plugmem-0.7.1-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.1-cp310-abi3-win_amd64.whl
Algorithm Hash digest
SHA256 7ca4ceea6123866f2716a8c504f7f166108684d63b80750a198b43740dc15293
MD5 79bf0ae053e4ea81c58ace592cf80d9f
BLAKE2b-256 02bc35864f0336902fd7837e066494a590eb1e5dbfcdc27f5b1777a4b99337be

See more details on using hashes here.

Provenance

The following attestation bundles were made for plugmem-0.7.1-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.1-cp310-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.

File metadata

File hashes

Hashes for plugmem-0.7.1-cp310-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
Algorithm Hash digest
SHA256 84f4e4672b905dc3d2d46b8ca7d433e3fa5978e10e5bd3f6ae29540d585029b7
MD5 aacb53d67c5df068819461efcae0f41e
BLAKE2b-256 6a0710c4aea949090213ec0a94feb98776e93829d619a233c89aaeaf172e8f61

See more details on using hashes here.

Provenance

The following attestation bundles were made for plugmem-0.7.1-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.1-cp310-abi3-manylinux_2_17_aarch64.manylinux2014_aarch64.whl.

File metadata

File hashes

Hashes for plugmem-0.7.1-cp310-abi3-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
Algorithm Hash digest
SHA256 638c9c240f45cbd0f9fb527621160af7d0d03df82f05fcdef36bc75a0cdc9f42
MD5 f569f3d3296e1d87ced2a9ad3d29b9c7
BLAKE2b-256 2c88179ac7fcdf40504ac71029a6c1cccdc3b06712b1641633f952aa78156212

See more details on using hashes here.

Provenance

The following attestation bundles were made for plugmem-0.7.1-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.1-cp310-abi3-macosx_11_0_arm64.whl.

File metadata

File hashes

Hashes for plugmem-0.7.1-cp310-abi3-macosx_11_0_arm64.whl
Algorithm Hash digest
SHA256 cb458177f5d735c720b8182df4fa55bb6600a5d080fd858d12f52baf014ac6d0
MD5 51f043496cd1ab5b38fe88206b3bbb2d
BLAKE2b-256 a6054b3b276b1f9e8b710309e056ae7ea55000890e78839d47d05784f8663113

See more details on using hashes here.

Provenance

The following attestation bundles were made for plugmem-0.7.1-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.1-cp310-abi3-macosx_10_12_x86_64.whl.

File metadata

File hashes

Hashes for plugmem-0.7.1-cp310-abi3-macosx_10_12_x86_64.whl
Algorithm Hash digest
SHA256 62c31ab28913e09518f97356625fdebb2551686e4d3e325ca28071538de6d40c
MD5 be7b96e2daf59c702a0092d587bff1b7
BLAKE2b-256 54c02d13e8b72efe9962d878f26ca16bdd2a533c6890aaa84c6aca84730773bd

See more details on using hashes here.

Provenance

The following attestation bundles were made for plugmem-0.7.1-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