basic-memory 0.17.5__tar.gz → 0.17.6__tar.gz

{basic_memory-0.17.5 → basic_memory-0.17.6}/CHANGELOG.md

@@ -1,5 +1,18 @@
 # CHANGELOG
 
+## v0.17.6 (2026-01-17)
+
+### Bug Fixes
+
+- **#510**: Fix Docker container Python symlink broken at runtime
+  ([`1799c94`](https://github.com/basicmachines-co/basic-memory/commit/1799c94))
+
+### Internal
+
+- Remove logfire config and specs docs, reduce lifespan and sync logging to debug level
+  ([`d1d433d`](https://github.com/basicmachines-co/basic-memory/commit/d1d433d),
+  [`803f3ef`](https://github.com/basicmachines-co/basic-memory/commit/803f3ef))
+
 ## v0.17.5 (2026-01-11)
 
 ### Bug Fixes

{basic_memory-0.17.5 → basic_memory-0.17.6}/Dockerfile

@@ -8,8 +8,13 @@ ARG GID=1000
 COPY --from=ghcr.io/astral-sh/uv:latest /uv /uvx /bin/
 
 # Set environment variables
+# UV_PYTHON_INSTALL_DIR ensures Python is installed to a persistent location
+# that survives in the final image (not in /root/.local which gets lost)
+# UV_PYTHON_PREFERENCE=only-managed tells uv to use its managed Python version
 ENV PYTHONUNBUFFERED=1 \
-    PYTHONDONTWRITEBYTECODE=1
+    PYTHONDONTWRITEBYTECODE=1 \
+    UV_PYTHON_INSTALL_DIR=/python \
+    UV_PYTHON_PREFERENCE=only-managed
 
 # Create a group and user with the provided UID/GID
 # Check if the GID already exists, if not create appgroup
@@ -19,9 +24,10 @@ RUN (getent group ${GID} || groupadd --gid ${GID} appgroup) && \
 # Copy the project into the image
 ADD . /app
 
-# Sync the project into a new environment, asserting the lockfile is up to date
+# Install Python 3.13 explicitly and sync the project
 WORKDIR /app
-RUN uv sync --locked
+RUN uv python install 3.13
+RUN uv sync --locked --python 3.13
 
 # Create necessary directories and set ownership
 RUN mkdir -p /app/data/basic-memory /app/.basic-memory && \
@@ -43,4 +49,4 @@ HEALTHCHECK --interval=30s --timeout=10s --start-period=5s --retries=3 \
     CMD basic-memory --version || exit 1
 
 # Use the basic-memory entrypoint to run the MCP server with default SSE transport
-CMD ["basic-memory", "mcp", "--transport", "sse", "--host", "0.0.0.0", "--port", "8000"]
+CMD ["basic-memory", "mcp", "--transport", "sse", "--host", "0.0.0.0", "--port", "8000"]

{basic_memory-0.17.5 → basic_memory-0.17.6}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: basic-memory
-Version: 0.17.5
+Version: 0.17.6
 Summary: Local-first knowledge management combining Zettelkasten with knowledge graphs
 Project-URL: Homepage, https://github.com/basicmachines-co/basic-memory
 Project-URL: Repository, https://github.com/basicmachines-co/basic-memory

{basic_memory-0.17.5 → basic_memory-0.17.6}/justfile

@@ -220,6 +220,11 @@ release version:
     echo "✅ Release {{version}} created successfully!"
     echo "📦 GitHub Actions will build and publish to PyPI"
     echo "🔗 Monitor at: https://github.com/basicmachines-co/basic-memory/actions"
+    echo ""
+    echo "📝 REMINDER: Update documentation sites after release is published:"
+    echo "   1. docs.basicmemory.com - Add release notes to src/pages/latest-releases.mdx"
+    echo "   2. basicmachines.co - Update version in src/components/sections/hero.tsx"
+    echo "   See: .claude/commands/release/release.md for detailed instructions"
 
 # Create a beta release (e.g., just beta v0.13.2b1)
 beta version:
@@ -281,6 +286,11 @@ beta version:
     echo "📦 GitHub Actions will build and publish to PyPI as pre-release"
     echo "🔗 Monitor at: https://github.com/basicmachines-co/basic-memory/actions"
     echo "📥 Install with: uv tool install basic-memory --pre"
+    echo ""
+    echo "📝 REMINDER: For stable releases, update documentation sites:"
+    echo "   1. docs.basicmemory.com - Add release notes to src/pages/latest-releases.mdx"
+    echo "   2. basicmachines.co - Update version in src/components/sections/hero.tsx"
+    echo "   See: .claude/commands/release/release.md for detailed instructions"
 
 # List all available recipes
 default:

{basic_memory-0.17.5 → basic_memory-0.17.6}/pyproject.toml

@@ -146,6 +146,3 @@ omit = [
     "*/telemetry.py",              # External analytics; tested lightly, excluded from strict coverage target
     "*/services/migration_service.py", # Complex migration scenarios
 ]
-
-[tool.logfire]
-ignore_no_config = true

{basic_memory-0.17.5 → basic_memory-0.17.6}/src/basic_memory/__init__.py

@@ -1,7 +1,7 @@
 """basic-memory - Local-first knowledge management combining Zettelkasten with knowledge graphs"""
 
 # Package version - updated by release automation
-__version__ = "0.17.5"
+__version__ = "0.17.6"
 
 # API version for FastAPI - independent of package version
 __api_version__ = "v0"

{basic_memory-0.17.5 → basic_memory-0.17.6}/src/basic_memory/cli/app.py

@@ -1,9 +1,3 @@
-# Suppress Logfire "not configured" warning - we only use Logfire in cloud/server contexts
-import os
-
-os.environ.setdefault("LOGFIRE_IGNORE_NO_CONFIG", "1")
-
-# Remove loguru's default handler IMMEDIATELY, before any other imports.
 # This prevents DEBUG logs from appearing on stdout during module-level
 # initialization (e.g., template_loader.TemplateLoader() logs at DEBUG level).
 from loguru import logger

{basic_memory-0.17.5 → basic_memory-0.17.6}/src/basic_memory/cli/commands/cloud/core_commands.py

@@ -139,7 +139,6 @@ def status() -> None:
 def setup() -> None:
     """Set up cloud sync by installing rclone and configuring credentials.
 
-    SPEC-20: Simplified to project-scoped workflow.
     After setup, use project commands for syncing:
       bm project add <name> <path> --local-path ~/projects/<name>
       bm project bisync --name <name> --resync  # First time

{basic_memory-0.17.5 → basic_memory-0.17.6}/src/basic_memory/mcp/server.py

@@ -28,7 +28,7 @@ async def lifespan(app: FastMCP):
     container = McpContainer.create()
     set_container(container)
 
-    logger.info(f"Starting Basic Memory MCP server (mode={container.mode.name})")
+    logger.debug(f"Starting Basic Memory MCP server (mode={container.mode.name})")
 
     # Show telemetry notice (first run only) and track startup
     show_notice_if_needed()
@@ -50,13 +50,13 @@ async def lifespan(app: FastMCP):
         yield
     finally:
         # Shutdown - coordinator handles clean task cancellation
-        logger.info("Shutting down Basic Memory MCP server")
+        logger.debug("Shutting down Basic Memory MCP server")
         await sync_coordinator.stop()
 
         # Only shutdown DB if we created it (not if test fixture provided it)
         if engine_was_none:
             await db.shutdown_db()
-            logger.info("Database connections closed")
+            logger.debug("Database connections closed")
         else:  # pragma: no cover
             logger.debug("Skipping DB shutdown - engine provided externally")
 

{basic_memory-0.17.5 → basic_memory-0.17.6}/src/basic_memory/sync/coordinator.py

@@ -78,7 +78,7 @@ class SyncCoordinator:
         """
         if not self.should_sync:
             if self.skip_reason:
-                logger.info(f"{self.skip_reason} - skipping local file sync")
+                logger.debug(f"{self.skip_reason} - skipping local file sync")
             self._status = SyncStatus.STOPPED
             return
 

basic_memory-0.17.5/specs/SPEC-1 Specification-Driven Development Process.md

@@ -1,156 +0,0 @@
----
-title: 'SPEC-1: Specification-Driven Development Process'
-type: spec
-permalink: specs/spec-1-specification-driven-development-process
-tags:
-- process
-- specification
-- development
-- meta
----
-
-# SPEC-1: Specification-Driven Development Process
-
-## Why
-We're implementing specification-driven development to solve the complexity and circular refactoring issues in our web development process. 
-Instead of getting lost in framework details and type gymnastics, we start with clear specifications that drive implementation.
-
-The default approach of adhoc development with AI agents tends to result in:
-- Circular refactoring cycles
-- Fighting framework complexity
-- Lost context between sessions
-- Unclear requirements and scope
-
-## What
-This spec defines our process for using basic-memory as the specification engine to build basic-memory-cloud. 
-We're creating a recursive development pattern where basic-memory manages the specs that drive the development of basic-memory-cloud.
-
-**Affected Areas:**
-- All future component development
-- Architecture decisions
-- Agent collaboration workflows
-- Knowledge management and context preservation
-
-## How (High Level)
-
-### Specification Structure
-
-Name: Spec names should be numbered sequentially, followed by a description eg. `SPEC-X - Simple Description.md`.
-See: [[Spec-2: Slash Commands Reference]]
-
-Every spec is a complete thought containing:
-- **Why**: The reasoning and problem being solved
-- **What**: What is affected or changed
-- **How**: High-level approach to implementation
-- **How to Evaluate**: Testing/validation procedure
-- Additional context as needed
-
-### Living Specification Format
-
-Specifications are **living documents** that evolve throughout implementation:
-
-**Progress Tracking:**
-- **Completed items**: Use ✅ checkmark emoji for implemented features
-- **Pending items**: Use `- [ ]` GitHub-style checkboxes for remaining tasks
-- **In-progress items**: Use `- [x]` when work is actively underway
-
-**Status Philosophy:**
-- **Avoid static status headers** like "COMPLETE" or "IN PROGRESS" that become stale
-- **Use checklists within content** to show granular implementation progress
-- **Keep specs informative** while providing clear progress visibility
-- **Update continuously** as understanding and implementation evolve
-
-**Example Format:**
-```markdown
-### ComponentName
-- ✅ Basic functionality implemented
-- ✅ Props and events defined
-- - [ ] Add sorting controls
-- - [ ] Improve accessibility
-- - [x] Currently implementing responsive design
-```
-
-This creates **git-friendly progress tracking** where `[ ]` easily becomes `[x]` or ✅ when completed, and specs remain valuable throughout the development lifecycle.
-
-
-## Claude Code 
-
-We will leverage Claude Code capabilities to make the process semi-automated. 
-
-- Slash commands: define repeatable steps in the process (create spec, implement, review, etc)
-- Agents: define roles to carry out instructions  (front end developer, baskend developer, etc)
-- MCP tools: enable agents to implement specs via actions (write code, test, etc)
-
-### Workflow
-1. **Create**: Write spec as complete thought in `/specs` folder
-2. **Discuss**: Iterate and refine through agent collaboration
-3. **Implement**: Hand spec to appropriate specialist agent
-4. **Validate**: Review implementation against spec criteria
-5. **Document**: Update spec with learnings and decisions
-
-### Slash Commands
-
-Claude slash commands are used to manage the flow.
-These are simple instructions to help make the process uniform. 
-They can be updated and refined as needed. 
-
-- `/spec create [name]` - Create new specification
-- `/spec status` - Show current spec states
-- `/spec implement [name]` - Hand to appropriate agent
-- `/spec review [name]` - Validate implementation
-
-### Agent Orchestration
-
-Agents are defined with clear roles, for instance:
-
-- **system-architect**: Creates high-level specs, ADRs, architectural decisions
-- **vue-developer**: Component specs, UI patterns, frontend architecture
-- **python-developer**: Implementation specs, technical details, backend logic
-- 
-- Each agent reads/updates specs through basic-memory tools. 
-
-## How to Evaluate
-
-### Success Criteria
-- Specs provide clear, actionable guidance for implementation
-- Reduced circular refactoring and scope creep
-- Persistent context across development sessions
-- Clean separation between "what/why" and implementation details
-- Specs record a history of what happened and why for historical context
-
-### Testing Procedure
-1. Create a spec for an existing problematic component
-2. Have an agent implement following only the spec
-3. Compare result quality and development speed vs. ad-hoc approach
-4. Measure context preservation across sessions
-5. Evaluate spec clarity and completeness
-
-### Metrics
-- Time from spec to working implementation
-- Number of refactoring cycles required
-- Agent understanding of requirements
-- Spec reusability for similar components
-
-## Notes
-- Start simple: specs are just complete thoughts, not heavy processes
-- Use basic-memory's knowledge graph to link specs, decisions, components
-- Let the process evolve naturally based on what works
-- Focus on solving the actual problem: Manage complexity in development
-
-## Observations
-
-- [problem] Web development without clear goals and documentation circular refactoring cycles #complexity
-- [solution] Specification-driven development reduces scope creep and context loss #process-improvement  
-- [pattern] basic-memory as specification engine creates recursive development loop #meta-development
-- [workflow] Five-step process: Create → Discuss → Implement → Validate → Document #methodology
-- [tool] Slash commands provide uniform process automation #automation
-- [agent-pattern] Three specialized agents handle different implementation domains #specialization
-- [success-metric] Time from spec to working implementation measures process efficiency #measurement
-- [learning] Process should evolve naturally based on what works in practice #adaptation
-- [format] Living specifications use checklists for progress tracking instead of static status headers #documentation
-- [evolution] Specs evolve throughout implementation maintaining value as working documents #continuous-improvement
-
-## Relations
-
-- spec [[Spec-2: Slash Commands Reference]]
-- spec [[Spec-3: Agent Definitions]]