Skip to content

feat: Linux build support + dynamic runtime paths#24

Open
scottzx wants to merge 3 commits into
mode-io:mainfrom
scottzx:linux-release
Open

feat: Linux build support + dynamic runtime paths#24
scottzx wants to merge 3 commits into
mode-io:mainfrom
scottzx:linux-release

Conversation

@scottzx
Copy link
Copy Markdown

@scottzx scottzx commented May 11, 2026

Summary

  • Linux platform support: Build script now detects OS (linux/darwin) and produces correctly-named artifacts
  • Dynamic runtime paths: Settings API serves storePath / marketplacePath from backend, frontend no longer hardcodes macOS-only paths
  • Unified Linux directories: On Linux, config/data/state lives under ~/.skill-manager
  • Architecture naming: ARM64 → aarch64 for cross-platform consistency

Changes

File Change
scripts/build_release.py OS detection, Linux artifact naming, arch rename
skill_manager/paths.py Linux: unified ~/.skill-manager root
skill_manager/application/settings/presenters.py Expose storePath / marketplacePath in settings API
frontend/.../settings/api/types.ts Add storePath / marketplacePath to interface
frontend/.../screens/SettingsPage.tsx Remove hardcoded macOS paths

Verified

  • Deployed on Linux ARM device (192.168.31.208:8000)

🤖 Generated with Claude Code

scottzx added 3 commits May 11, 2026 18:14
- Created localization files for MCP servers, overview, settings, skills, and slash commands in Chinese (zh-CN).
- Implemented translation service to handle localization dynamically.
- Added error messages and marketplace notifications in both English and Chinese.
- Updated overview snapshot to reflect new localization structure.
@SI-RUI-ZHANG
Copy link
Copy Markdown
Contributor

Hi @scottzx, thank you for opening this. I really appreciate it, especially because this is one of the first external contributions to Skill Manager. Your Linux ARM validation is useful signal, and the direction is valuable.

I did an initial review. There are a couple of ideas here that I want to keep:

  • exposing runtime paths from the backend instead of hardcoding macOS paths in the frontend
  • making release artifacts OS/architecture-aware
  • validating the app on Linux

I cannot merge this PR as-is because it also includes several unrelated changes, including i18n, a default port change, broad frontend rewrites, API error translation changes, and a snapshot/debug file. That makes the Linux support hard to review safely.

To keep the project history clean, I’m going to create a smaller maintainer branch for the Linux support work and credit this PR / your contribution in the PR description. I’ll keep the scope narrow: Linux paths, artifact naming, CI/package smoke, and Settings path display.

Thank you again. This PR is helpful as the starting point for Linux support, even if we don’t merge this exact branch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants