Open
Conversation
…ta path override - Updated `_generate_index_html` to escape `</` in JSON to prevent early script tag closure. - Modified `JacSuperConsole` to use stderr console based on `JAC_USE_STDERR` environment variable. - Enhanced `JacConsole.print` to redirect output to stderr if `JAC_USE_STDERR` is set, and improved flushing mechanism. - Improved `Scheduler.stop` method to check for `None` before setting stop and done events. - Added support for overriding data directory path via `JAC_DATA_PATH` environment variable in `UserManager.postinit`. - Enhanced error handling and logging in `JacAPIServer` methods, including detailed output for GET and POST requests. - Updated `get_db_path` to allow data path override for read-only deployments, ensuring compatibility with AppImage and sidecar modes.
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
…features and fixes
for more information, see https://pre-commit.ci
Root cause: jac_client was a namespace package (no __init__.py) while jac_scale had __init__.py at every level. In PyInstaller frozen apps, Python's PathFinder handles dirs with __init__.py correctly but creates broken namespace packages for dirs without — preventing JacMetaImporter from loading __init__.jac files. Fix: Add __init__.py to all jac_client directories, matching jac_scale's packaging pattern. This lets collect_all() bundle properly, Python sets up __path__ correctly, and JacMetaImporter handles .jac files within. Removed: explicit jac_client bundling workaround, JACPATH hack, _ensure_frozen_search_paths, and debug logging. jac_client is now bundled identically to jac_scale via collect_all().
Directories with __init__.jac (plugin/, plugin/src/, plugin/utils/) need __init__.py that re-exports the same symbols via Python imports. Without this, Python treats them as empty namespace packages in frozen PyInstaller apps, and __init__.jac exports are never loaded. The __init__.py imports jaclang first (registers JacMetaImporter), then imports from the .jac submodules so the exports are available to importlib.import_module().
Comprehensive documentation of all Windows compatibility changes, development rules, architecture decisions, and known issues. Includes sidecar API test script for endpoint verification.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
When client_only = true in [desktop] section of jac.toml, skip sidecar bundling and require a remote base_url instead. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…rtup Prevents MCP servers from launching during jac build by setting JAC_BUILD=1 while compiling the web bundle.
jac_client contains the sidecar entry point, so it must always be bundled regardless of the [desktop.plugins] config. Also adds jac_mcp to default plugin config and spec template. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Tauri drops the stdout pipe after reading JAC_SIDECAR_PORT, causing subsequent console.print/flush calls to crash with OSError [Errno 22]. Redirecting stdout to stderr after port write keeps logs flowing. Also added debug logs to console.impl.jac pipe error catch blocks. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The rglob('*.jac') in the spec template was picking up .jac files from
inside previous sidecar builds (src-tauri/binaries/), causing recursive
nesting that exceeded Windows path limits and broke NSIS bundling.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
jac_client is always bundled as a core package since the sidecar entry point depends on it. Listing it in the plugin config is misleading as it suggests users can disable it. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
get_bun was added to __init__.py but never declared in bun_installer.jac on this branch. Causes ImportError on fresh installs.
jac-client calls 'cargo tauri build' which requires tauri-cli as a Cargo subcommand. The bun global install put it on PATH as standalone 'tauri' but not as 'cargo tauri'. cargo-binstall downloads a pre-built binary (~10s) instead of compiling from source (~8 min).
Three build failures fixed: - Windows: icon.ico was missing. Add 'cargo tauri icon' step after setup to generate .ico from the default icon.png. - macOS: 'No matching IconType' because Tauri needs .icns format. Same 'cargo tauri icon' step generates it. - Linux: 'failed to run linuxdeploy' because GitHub runners lack FUSE device access. Set APPIMAGE_EXTRACT_AND_RUN=1 so AppImage tools extract instead of mounting.
Replace _generate_ico_from_png with _generate_platform_icons that produces every format Tauri needs: icon.ico (Windows), icon.icns (macOS), and standard PNG sizes (32, 128, 256, 128x128@2x) for Linux. Previously only icon.png was generated, causing cargo tauri build to fail on Windows (missing .ico) and macOS (No matching IconType). Remove cargo tauri icon CI step since the build now handles all icon formats natively via Pillow.
'pass' is not supported in Jac. Use a comment instead for the empty ImportError handler in _generate_platform_icons.
The icon scanner only picked up .png and .ico files, so icon.icns was never added to bundle.icon in tauri.conf.json. Tauri's macOS bundler needs .icns listed there, causing 'No matching IconType' on macOS.
…n platform derivatives The old _generate_default_icons had three methods (PIL subprocess, ImageMagick, hand-crafted bytes) but methods 1 and 2 returned early, so _generate_platform_icons never ran when PIL or ImageMagick was available. This meant .ico, .icns, and sized PNGs were only generated from the hand-crafted fallback path. Rewrite to: - Try Pillow in-process first (no subprocess, better quality with white border detail, guaranteed valid RGBA PNG) - Fall back to hand-crafted bytes only if Pillow is not installed - Always call _generate_platform_icons regardless of which method created icon.png, so .ico/.icns/sized PNGs are always produced
Move Linux AppImage env vars into the build step's env block (more reliable than GITHUB_ENV). Add NO_STRIP=true to prevent linuxdeploy from failing on binary stripping in CI runner environments.
Two fixes: - cargo binstall tauri-cli --force: cached binary from previous runs caused 'already exists' error on macOS/Windows. - Move APPIMAGE_EXTRACT_AND_RUN back to dedicated step with GITHUB_ENV (ternary expression in env block was unreliable).
The cache restored src-tauri/target/ which created src-tauri/ directory. jac setup desktop then saw src-tauri/ exists and skipped setup entirely, never generating src/main.rs. Remove src-tauri/target from cache paths so setup always runs cleanly. Cargo registry/git/bin cache is kept for faster dependency downloads.
Three fixes: - Remove ~/.cargo/bin from cache (was caching stale tauri-cli binary). Change cache key prefix so old cache is never restored. - Tauri CLI install: try binstall with --no-discover-github-token to avoid 403 rate limits, fall back to cargo install --locked. - Always rm -rf src-tauri before jac setup desktop so stale dirs from any source can't trick setup into skipping.
linuxdeploy requires FUSE which GitHub runners don't provide. The APPIMAGE_EXTRACT_AND_RUN env var doesn't work with Tauri's bundler. Instead, set bundle.targets to ['deb', 'rpm'] in tauri.conf.json after setup. deb and rpm already built successfully on prior runs.
jac build --platform <x> passes --target <triple> to Cargo, so bundles land under target/<triple>/release/bundle/ rather than target/release/bundle/. Update List and Upload steps to use target/**/release/bundle/**/* to match either layout. Also add missing *.rpm to the upload patterns.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description