memorysync-cli 1.0.2__tar.gz

memorysync_cli-1.0.2/.gitignore

@@ -0,0 +1,66 @@
+# ==============================================================================
+# MemorySync — Git Ignore Rules (Transparency-First Philosophy)
+# ==============================================================================
+
+# -------------------------
+# Category 1: Secrets & Credentials (NEVER COMMIT)
+# -------------------------
+.env
+.env.*
+!memorysync-benchmark/longmemeval/.env.example
+*.pem
+*.key
+*.crt
+secrets/
+
+# -------------------------
+# Category 2: User / Customer / Private Data (NEVER COMMIT)
+# -------------------------
+uploads/
+backups/
+/storage/
+chroma/
+chroma_data/
+*.db
+*.sqlite
+*.sqlite3
+*.dump
+*.bak
+
+# -------------------------
+# Category 3: Massive Dependency / Build / Cache Artifacts (BLOAT)
+# -------------------------
+node_modules/
+venv/
+.venv/
+__pycache__/
+.pytest_cache/
+.next/
+dist/
+build/
+htmlcov/
+.coverage
+*.cover
+out/
+/dashboard/tsconfig.tsbuildinfo
+
+# Responsive audit output (regenerated by npm run audit:responsive)
+dashboard/responsive-audit-report.json
+
+# -------------------------
+# Category 4: Local worktrees and deploy clones (NEVER COMMIT)
+# -------------------------
+# Each of these holds its own .git directory. Staging one would record a
+# gitlink with no matching .gitmodules entry, which reads as a broken
+# submodule for everyone who clones afterwards, and it would drag several
+# thousand unrelated files in with it.
+#
+# They are also why `git add .` stalls here rather than finishing: the walk
+# has to touch roughly two thousand extra files, and because this repo lives
+# under OneDrive, each one can trigger a hydration download before git is
+# allowed to read it.
+/.kiro/worktrees/
+/.production-deploy/
+/.baseline-int/
+/.baseline-plan/
+/.baseline-s3/

memorysync_cli-1.0.2/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2025 MemorySync
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

memorysync_cli-1.0.2/PKG-INFO

@@ -0,0 +1,158 @@
+Metadata-Version: 2.5
+Name: memorysync-cli
+Version: 1.0.2
+Summary: MemorySync from your terminal. Zero dependencies.
+Project-URL: Documentation, https://docs.memorysync.io/cli
+Project-URL: Homepage, https://memorysync.io/cli
+Author: MemorySync
+License: MIT
+License-File: LICENSE
+Keywords: agent-memory,ai-agents,cli,llm,long-term-memory,memory,memorysync,terminal
+Classifier: Development Status :: 5 - Production/Stable
+Classifier: Environment :: Console
+Classifier: Intended Audience :: Developers
+Classifier: License :: OSI Approved :: MIT License
+Classifier: Programming Language :: Python :: 3
+Classifier: Programming Language :: Python :: 3.9
+Classifier: Programming Language :: Python :: 3.10
+Classifier: Programming Language :: Python :: 3.11
+Classifier: Programming Language :: Python :: 3.12
+Classifier: Programming Language :: Python :: 3.13
+Classifier: Topic :: Software Development :: Libraries
+Classifier: Topic :: Utilities
+Requires-Python: >=3.9
+Description-Content-Type: text/markdown
+
+# memorysync-cli (Python)
+
+MemorySync from your terminal. Zero dependencies.
+
+The same CLI as the npm package `memorysync-cli`, implemented in Python. Same 21
+commands, same flags, same output formats, same exit codes. The two are
+interchangeable, so you only need one.
+
+```bash
+pipx install memorysync-cli
+```
+
+`pipx` is recommended because this is an application rather than a library. `pip
+install` works too, but outside a virtual environment it fails on
+externally-managed Pythons — Homebrew and most Linux distributions — with
+`externally-managed-environment` ([PEP 668](https://peps.python.org/pep-0668/)).
+
+Requires Python 3.9 or newer.
+
+## Getting started
+
+```bash
+memorysync init                       # store a key, pick a default user
+memorysync add "Prefers pnpm" --user alice
+memorysync search "package manager" --user alice
+memorysync quota                      # how much of the plan is left
+```
+
+Both `memorysync` and `msync` are installed; `msync` is just shorter.
+
+## Parity is enforced, not promised
+
+Both CLIs read one generated command tree, so `help --json` is byte-identical
+between them. The test suite runs both and compares stdout for every offline
+command, including all four completion scripts, and compares exit codes for each
+failure mode. A command added to one and not the other fails the build.
+
+That matters because the alternative does not hold. Mem0 ships a Node and a Python
+CLI and documents them as identical; their Python CLI answers `help --json` with
+twelve commands while their Node CLI answers with a name, a version and a
+description and no commands at all, and the two sit on different versions.
+
+## Zero dependencies
+
+`argparse`, `urllib.request` and `json` cover everything. Mem0's Python CLI depends
+on httpx, rich and typer.
+
+Every dependency is code on a customer's machine that they cannot audit on our
+behalf, which matters more for a closed-source tool because nobody else is reading
+our lockfile. A table and eight colours do not justify it.
+
+## Agent mode
+
+Pass `--json` (or `--agent`) before the command for one JSON envelope, no colour,
+no spinners, errors as JSON with a non-zero exit:
+
+```bash
+memorysync --json search "preferences" --user alice
+```
+
+`data` is always a list, for every command. An agent parses one shape rather than
+remembering which commands return an object.
+
+```bash
+memorysync help --json     # the whole command tree, for self-discovery
+```
+
+## Exit codes
+
+A script can branch on the cause rather than parsing prose.
+
+| Code | Meaning |
+|------|---------|
+| 0 | Success |
+| 1 | Unclassified failure |
+| 2 | Usage: unknown command, bad flag, bad value |
+| 3 | Auth: missing, expired or revoked credentials |
+| 4 | Quota: a plan limit is reached |
+| 5 | Network: unreachable or timed out |
+| 6 | Not found |
+| 130 | Interrupted |
+
+Code 4 earns its place. Over a plan limit the API returns success with an empty
+result rather than an error, deliberately, so an assistant never narrates billing
+state to an end user. From a terminal that silence is unhelpful, so the CLI reads
+usage and turns it into a distinct code — otherwise an exhausted plan is
+indistinguishable from an empty database.
+
+## Where your key is stored
+
+Never in the config file. In order: `MEMORYSYNC_API_KEY`, then the OS keychain,
+then an owner-only encrypted file.
+
+| Platform | Storage |
+|---|---|
+| macOS | Keychain, via `security` |
+| Linux | Keyring, via `secret-tool`, when libsecret is present |
+| Windows | Owner-only encrypted file |
+
+Windows has no scriptable Credential Manager path that avoids a dependency, so it
+uses the file tier. That is the same on the Node CLI. The file is `0600` and its
+contents are tied to the machine and user, which stops a casual `cat` or a backup
+scraper; anyone who can already run code as you can read it. The keychain is
+better, which is why it is tried first.
+
+## Deleting
+
+`delete` is two-step by default: without `--yes` it previews and changes nothing.
+
+`delete --all` clears that one end user's memories and nothing else. No form of any
+command can delete an account, a project or an API key.
+
+To clear every memory for an end user through the API directly, use a wide filter
+on `DELETE /memory/forget`, for example `{"before": "<now>"}`. Not
+`/memory/user/purge`: despite its path it is not end-user scoped and erases the
+account behind the credential.
+
+## Environment variables
+
+| Variable | Purpose |
+|---|---|
+| `MEMORYSYNC_API_KEY` | Key, highest priority |
+| `MEMORYSYNC_BASE_URL` | API base URL |
+| `MEMORYSYNC_USER` | Default end user |
+| `MEMORYSYNC_PROJECT` | Default project |
+| `MEMORYSYNC_PROFILE` | Named profile |
+| `MEMORYSYNC_OUTPUT` | Default output format |
+| `MEMORYSYNC_CONFIG_DIR` | Where config and credentials live |
+| `NO_COLOR` | Disable colour |
+
+## Documentation
+
+<https://docs.memorysync.io/cli>

memorysync_cli-1.0.2/README.md

@@ -0,0 +1,133 @@
+# memorysync-cli (Python)
+
+MemorySync from your terminal. Zero dependencies.
+
+The same CLI as the npm package `memorysync-cli`, implemented in Python. Same 21
+commands, same flags, same output formats, same exit codes. The two are
+interchangeable, so you only need one.
+
+```bash
+pipx install memorysync-cli
+```
+
+`pipx` is recommended because this is an application rather than a library. `pip
+install` works too, but outside a virtual environment it fails on
+externally-managed Pythons — Homebrew and most Linux distributions — with
+`externally-managed-environment` ([PEP 668](https://peps.python.org/pep-0668/)).
+
+Requires Python 3.9 or newer.
+
+## Getting started
+
+```bash
+memorysync init                       # store a key, pick a default user
+memorysync add "Prefers pnpm" --user alice
+memorysync search "package manager" --user alice
+memorysync quota                      # how much of the plan is left
+```
+
+Both `memorysync` and `msync` are installed; `msync` is just shorter.
+
+## Parity is enforced, not promised
+
+Both CLIs read one generated command tree, so `help --json` is byte-identical
+between them. The test suite runs both and compares stdout for every offline
+command, including all four completion scripts, and compares exit codes for each
+failure mode. A command added to one and not the other fails the build.
+
+That matters because the alternative does not hold. Mem0 ships a Node and a Python
+CLI and documents them as identical; their Python CLI answers `help --json` with
+twelve commands while their Node CLI answers with a name, a version and a
+description and no commands at all, and the two sit on different versions.
+
+## Zero dependencies
+
+`argparse`, `urllib.request` and `json` cover everything. Mem0's Python CLI depends
+on httpx, rich and typer.
+
+Every dependency is code on a customer's machine that they cannot audit on our
+behalf, which matters more for a closed-source tool because nobody else is reading
+our lockfile. A table and eight colours do not justify it.
+
+## Agent mode
+
+Pass `--json` (or `--agent`) before the command for one JSON envelope, no colour,
+no spinners, errors as JSON with a non-zero exit:
+
+```bash
+memorysync --json search "preferences" --user alice
+```
+
+`data` is always a list, for every command. An agent parses one shape rather than
+remembering which commands return an object.
+
+```bash
+memorysync help --json     # the whole command tree, for self-discovery
+```
+
+## Exit codes
+
+A script can branch on the cause rather than parsing prose.
+
+| Code | Meaning |
+|------|---------|
+| 0 | Success |
+| 1 | Unclassified failure |
+| 2 | Usage: unknown command, bad flag, bad value |
+| 3 | Auth: missing, expired or revoked credentials |
+| 4 | Quota: a plan limit is reached |
+| 5 | Network: unreachable or timed out |
+| 6 | Not found |
+| 130 | Interrupted |
+
+Code 4 earns its place. Over a plan limit the API returns success with an empty
+result rather than an error, deliberately, so an assistant never narrates billing
+state to an end user. From a terminal that silence is unhelpful, so the CLI reads
+usage and turns it into a distinct code — otherwise an exhausted plan is
+indistinguishable from an empty database.
+
+## Where your key is stored
+
+Never in the config file. In order: `MEMORYSYNC_API_KEY`, then the OS keychain,
+then an owner-only encrypted file.
+
+| Platform | Storage |
+|---|---|
+| macOS | Keychain, via `security` |
+| Linux | Keyring, via `secret-tool`, when libsecret is present |
+| Windows | Owner-only encrypted file |
+
+Windows has no scriptable Credential Manager path that avoids a dependency, so it
+uses the file tier. That is the same on the Node CLI. The file is `0600` and its
+contents are tied to the machine and user, which stops a casual `cat` or a backup
+scraper; anyone who can already run code as you can read it. The keychain is
+better, which is why it is tried first.
+
+## Deleting
+
+`delete` is two-step by default: without `--yes` it previews and changes nothing.
+
+`delete --all` clears that one end user's memories and nothing else. No form of any
+command can delete an account, a project or an API key.
+
+To clear every memory for an end user through the API directly, use a wide filter
+on `DELETE /memory/forget`, for example `{"before": "<now>"}`. Not
+`/memory/user/purge`: despite its path it is not end-user scoped and erases the
+account behind the credential.
+
+## Environment variables
+
+| Variable | Purpose |
+|---|---|
+| `MEMORYSYNC_API_KEY` | Key, highest priority |
+| `MEMORYSYNC_BASE_URL` | API base URL |
+| `MEMORYSYNC_USER` | Default end user |
+| `MEMORYSYNC_PROJECT` | Default project |
+| `MEMORYSYNC_PROFILE` | Named profile |
+| `MEMORYSYNC_OUTPUT` | Default output format |
+| `MEMORYSYNC_CONFIG_DIR` | Where config and credentials live |
+| `NO_COLOR` | Disable colour |
+
+## Documentation
+
+<https://docs.memorysync.io/cli>

memorysync_cli-1.0.2/pyproject.toml

@@ -0,0 +1,79 @@
+[build-system]
+requires = ["hatchling"]
+build-backend = "hatchling.build"
+
+[project]
+name = "memorysync-cli"
+# Taken from _version.py rather than written here. The Node CLI shipped 1.0.1
+# reporting 1.0.0 because the number lived in two places and one was bumped, and
+# the Python SDK shipped 1.7.1 reporting 1.7.0 for the same reason. One source.
+dynamic = ["version"]
+description = "MemorySync from your terminal. Zero dependencies."
+readme = "README.md"
+license = { text = "MIT" }
+# 3.9, matching the memorysync SDK. Mem0's CLI requires 3.10+, so this reaches
+# one more Python version than the only competitor shipping a Python CLI.
+requires-python = ">=3.9"
+authors = [{ name = "MemorySync" }]
+keywords = [
+  "memorysync",
+  "memory",
+  "cli",
+  "agent-memory",
+  "long-term-memory",
+  "ai-agents",
+  "llm",
+  "terminal",
+]
+classifiers = [
+  "Development Status :: 5 - Production/Stable",
+  "Environment :: Console",
+  "Intended Audience :: Developers",
+  "License :: OSI Approved :: MIT License",
+  "Programming Language :: Python :: 3",
+  "Programming Language :: Python :: 3.9",
+  "Programming Language :: Python :: 3.10",
+  "Programming Language :: Python :: 3.11",
+  "Programming Language :: Python :: 3.12",
+  "Programming Language :: Python :: 3.13",
+  "Topic :: Software Development :: Libraries",
+  "Topic :: Utilities",
+]
+
+# Deliberately empty.
+#
+# Mem0's Python CLI depends on httpx, rich and typer; their Node CLI on
+# commander, chalk, cli-table3, ora and boxen. Every one of those is code we would
+# be putting on a customer's machine that they cannot audit on our behalf, which
+# matters more for a closed-source tool because nobody else is reading our
+# lockfile. argparse, urllib.request and json cover all of it.
+dependencies = []
+
+[project.urls]
+Documentation = "https://docs.memorysync.io/cli"
+Homepage = "https://memorysync.io/cli"
+
+[project.scripts]
+# Both names, matching the Node CLI. The two implementations are interchangeable,
+# so whichever is on PATH behaves identically and nobody needs both.
+memorysync = "memorysync_cli.main:run"
+msync = "memorysync_cli.main:run"
+
+[tool.hatch.version]
+path = "src/memorysync_cli/_version.py"
+
+[tool.hatch.build.targets.wheel]
+packages = ["src/memorysync_cli"]
+
+[tool.hatch.build.targets.wheel.force-include]
+# registry.json is generated from the Node CLI and must be in the wheel: it is
+# the command surface, read at runtime, not a build-time convenience.
+"src/memorysync_cli/registry.json" = "memorysync_cli/registry.json"
+
+[tool.hatch.build.targets.sdist]
+include = [
+  "src/memorysync_cli",
+  "README.md",
+  "LICENSE",
+  "pyproject.toml",
+]

memorysync_cli-1.0.2/src/memorysync_cli/__init__.py

@@ -0,0 +1,13 @@
+"""MemorySync command-line interface.
+
+A Python implementation of the same CLI as the npm package ``memorysync-cli``,
+with the same commands, flags, output formats and exit codes. The two are
+interchangeable: whichever is on PATH behaves identically, so you only need one.
+
+Both read their command surface from one generated declaration, so ``help --json``
+is byte-identical between them rather than kept aligned by review.
+"""
+
+from ._version import __version__
+
+__all__ = ["__version__"]

memorysync_cli-1.0.2/src/memorysync_cli/__main__.py

@@ -0,0 +1,9 @@
+"""Allow ``python -m memorysync_cli`` alongside the installed console scripts.
+
+Useful during development and in environments where a wheel's scripts directory is
+not on PATH, which is common inside CI containers.
+"""
+
+from .main import run
+
+run()

memorysync_cli-1.0.2/src/memorysync_cli/_version.py

@@ -0,0 +1 @@
+__version__ = "1.0.2"