java-codebase-rag 0.11.2__py3-none-any.whl → 0.12.1__py3-none-any.whl

java_codebase_rag-0.12.1.dist-info/METADATA

@@ -0,0 +1,35 @@
+Metadata-Version: 2.4
+Name: java-codebase-rag
+Version: 0.12.1
+Summary: Renamed to jrag-cli; this package only depends on jrag-cli. New setups: pip install jrag-cli.
+Author: HumanBean17
+License-Expression: MIT
+Project-URL: Homepage, https://github.com/HumanBean17/jrag
+Project-URL: Repository, https://github.com/HumanBean17/jrag
+Project-URL: Issues, https://github.com/HumanBean17/jrag/issues
+Requires-Python: >=3.11
+Description-Content-Type: text/markdown
+Requires-Dist: jrag-cli==0.12.1
+
+# java-codebase-rag (renamed to `jrag-cli`)
+
+This package has been **renamed to [`jrag-cli`](https://github.com/HumanBean17/jrag)**.
+
+`java-codebase-rag` remains on PyPI as a thin compatibility shim that depends
+on `jrag-cli` and ships no code of its own. Upgrading an existing install
+pulls `jrag-cli` in transparently:
+
+```bash
+pip install -U java-codebase-rag   # installs jrag-cli behind the scenes
+```
+
+For new setups, install the canonical package directly:
+
+```bash
+pip install jrag-cli
+```
+
+The CLI entry points, MCP server, and module layout are unchanged — `jrag`
+and `jrag-mcp` (plus the legacy `java-codebase-rag` / `java-codebase-rag-mcp`
+aliases) are all provided by `jrag-cli`. See
+[HumanBean17/jrag](https://github.com/HumanBean17/jrag) for documentation.

java_codebase_rag-0.12.1.dist-info/RECORD

@@ -0,0 +1,4 @@
+java_codebase_rag-0.12.1.dist-info/METADATA,sha256=9lQjVtb3QIcEFHHmPAVZj3RFCQ41TsEa5h3rS3m2ChM,1264
+java_codebase_rag-0.12.1.dist-info/WHEEL,sha256=YVMoNqKzERt-wjUZwJ33xBGAwnFl-4cqbYkTtWa4itE,91
+java_codebase_rag-0.12.1.dist-info/top_level.txt,sha256=AbpHGcgLb-kRsJGnwFEktk7uzpZOCcBY74-YBdrKVGs,1
+java_codebase_rag-0.12.1.dist-info/RECORD,,

{java_codebase_rag-0.11.2.dist-info → java_codebase_rag-0.12.1.dist-info}/WHEEL

@@ -1,5 +1,5 @@
 Wheel-Version: 1.0
-Generator: setuptools (83.0.0)
+Generator: setuptools (84.0.0)
 Root-Is-Purelib: true
 Tag: py3-none-any
 

java_codebase_rag/_fdlimit.py

@@ -1,56 +0,0 @@
-"""Raise the process soft file-descriptor limit to avoid LanceDB EMFILE.
-
-LanceDB's merge-insert path opens many file handles concurrently; under the
-default OS soft ``RLIMIT_NOFILE`` (256 on macOS processes launched by GUI /
-launchd / IDE hosts, *not* the shell's raised limit) this exhausts file
-descriptors and surfaces as::
-
-    RuntimeError: lance error: LanceError(IO): ... Too many open files (os error 24)
-        lance-io-4.0.0/src/local.rs:133:24
-
-``raise_fd_limit`` raises the process's *own* soft limit toward its hard limit.
-``RLIMIT_NOFILE`` is inherited across ``fork``+``exec``, so every CocoIndex /
-``cocoindex-code`` child spawned afterwards inherits the headroom. This fixes the
-failure regardless of launch context (shell vs IDE vs MCP host) and regardless of
-Lance's internal IO concurrency.
-
-Never raise to ``RLIM_INFINITY`` — that breaks ``select()``/kqueue and Python
-selectors on macOS; ``cap`` bounds the target to a safe value.
-
-See https://github.com/HumanBean17/java-codebase-rag/issues/306
-"""
-
-from __future__ import annotations
-
-try:
-    # Unix-only: the ``resource`` module does not exist on Windows. Importing it
-    # unconditionally at module scope crashes on Windows, which (because
-    # ``cli.py`` and ``server.py`` both import ``raise_fd_limit``) made the
-    # entire CLI and MCP server fail to start there. Guard the import so the
-    # module loads everywhere; the function below no-ops when it's absent.
-    import resource
-except ImportError:  # pragma: no cover - Windows lacks the resource module
-    resource = None  # type: ignore[assignment]
-
-# Safe ceiling well above LanceDB's appetite, comfortably below macOS libc
-# quirks. The hard limit caps it further if lower (locked-down servers).
-_DEFAULT_CAP = 65536
-
-
-def raise_fd_limit(cap: int = _DEFAULT_CAP) -> None:
-    """Raise this process's soft ``RLIMIT_NOFILE`` toward its hard limit.
-
-    Best-effort and silent: never raises. No-op where ``RLIMIT_NOFILE`` is
-    unsupported (Windows) or where the soft limit already meets ``min(hard, cap)``.
-    """
-    if resource is None or not hasattr(resource, "RLIMIT_NOFILE"):
-        return
-    soft, hard = resource.getrlimit(resource.RLIMIT_NOFILE)
-    target = min(hard, cap)
-    if soft >= target:
-        return
-    try:
-        resource.setrlimit(resource.RLIMIT_NOFILE, (target, hard))
-    except (ValueError, OSError):
-        # Best-effort: a locked-down environment shouldn't fail the run.
-        pass

java_codebase_rag/_stdio.py

@@ -1,32 +0,0 @@
-"""Force stdout/stderr to UTF-8 so non-ASCII glyphs never crash the CLI.
-
-The text renderers emit Unicode glyphs — ``↑``/``↓`` (hierarchy tree headers
-in ``jrag_render``), ``✓`` (success markers in ``cli_format``), ``→``/``…``
-(listing/role lines). On Windows, ``sys.stdout``/``sys.stderr`` default to the
-system ANSI codepage (cp1252 on en-US Windows), which can't encode those
-characters, so ``print()`` raises ``UnicodeEncodeError`` and the process exits
-non-zero. Unix platforms already default to UTF-8, so this is a no-op there.
-
-Called from the console-script entry points (``_console_script_main``), not
-from in-process ``main()`` callers, so a test that drives ``main()`` directly
-keeps whatever stdout the host wired up.
-"""
-
-from __future__ import annotations
-
-import sys
-
-
-def force_utf8_stdio() -> None:
-    """Reconfigure ``sys.stdout``/``sys.stderr`` to UTF-8.
-
-    Best-effort and silent: never raises. No-op where a stream lacks
-    ``reconfigure`` (streams replaced by capture frameworks that don't expose
-    it). ``errors="replace"`` is a last-resort safety net so a hostile console
-    can never crash a run; under UTF-8 every codepoint encodes cleanly, so
-    replacement never actually fires for the glyphs we emit.
-    """
-    for stream in (sys.stdout, sys.stderr):
-        reconfigure = getattr(stream, "reconfigure", None)
-        if reconfigure is not None:
-            reconfigure(encoding="utf-8", errors="replace")

java_codebase_rag/_version.py

@@ -1,35 +0,0 @@
-"""Version string for the CLI ``--version`` flag.
-
-The single source of truth is the installed distribution metadata
-(``java-codebase-rag`` in pyproject.toml), read via :mod:`importlib.metadata`
-so a pyproject bump propagates with no second hardcoded copy.
-:func:`version_string` appends the CPython version for the
-``<prog> <version> (python <x.y.z>)`` format chosen for the ``--version`` flag.
-
-Stdlib-only on purpose: this is imported at module load by both CLIs, and
-``jrag`` keeps ``build_parser()`` free of torch / sentence_transformers / mcp_v2.
-"""
-from __future__ import annotations
-
-import platform
-from importlib.metadata import PackageNotFoundError
-from importlib.metadata import version as _dist_version
-
-_PACKAGE = "java-codebase-rag"
-
-
-def package_version() -> str:
-    """Installed distribution version, or ``"unknown"`` if metadata is absent.
-
-    Absent only when run from a raw checkout without ``pip install -e``; the
-    test suite (``conftest.py``) enforces editable install, so this is defensive.
-    """
-    try:
-        return _dist_version(_PACKAGE)
-    except PackageNotFoundError:  # pragma: no cover - defensive
-        return "unknown"
-
-
-def version_string(prog: str) -> str:
-    """Formatted ``--version`` output: ``<prog> <version> (python <x.y.z>)``."""
-    return f"{prog} {package_version()} (python {platform.python_version()})"