java-codebase-rag 0.12.0__py3-none-any.whl → 0.12.2__py3-none-any.whl

java_codebase_rag-0.12.2.dist-info/METADATA

@@ -0,0 +1,35 @@
+Metadata-Version: 2.4
+Name: java-codebase-rag
+Version: 0.12.2
+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.2
+
+# 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.2.dist-info/RECORD

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

{java_codebase_rag-0.12.0.dist-info → java_codebase_rag-0.12.2.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/_deprecation.py

@@ -1,103 +0,0 @@
-"""Legacy-alias deprecation notice for the ``jrag`` rename.
-
-The tool is being renamed from ``java-codebase-rag`` to ``jrag``. The legacy
-command aliases (``java-codebase-rag`` and ``java-codebase-rag-mcp``) continue
-to work; when invoked through one of them in an interactive context, this
-helper emits a single-line notice pointing the operator at the new name.
-
-Suppression rule
-----------------
-The notice is suppressed when **either** of the following holds:
-
-* ``$JRAG_NO_DEPRECATION`` is present and non-empty — any non-empty value
-  suppresses (so ``"1"``, ``"0"``, ``"false"``, ``"yes"`` all suppress; the
-  empty string and an unset variable do not). The simpler "present and
-  non-empty" rule is preferred over parsing truthy values so that operators
-  can shut the notice up with whatever value is easiest to reach for.
-* ``sys.stderr.isatty()`` is false (or ``sys.stderr`` lacks ``isatty``) — i.e.
-  non-interactive contexts: piped, redirected, or captured stderr. Under real
-  MCP use stderr is not a TTY, so the call is silent in production; it exists
-  for the rare human-debug case.
-
-This module is stdlib-only and import-light: it runs at MCP-server startup and
-before ``--help``, so it must not pull in any backend (cli, search, mcp) code.
-"""
-from __future__ import annotations
-
-import os
-import sys
-
-_LEGACY_ALIASES = frozenset({"java-codebase-rag", "java-codebase-rag-mcp"})
-
-_DEPRECATION_LINE = (
-    "jrag: 'java-codebase-rag' is now 'jrag'; this alias continues to work. "
-    "Set JRAG_NO_DEPRECATION=1 to silence.\n"
-)
-
-#: Executable suffixes appended by Windows (and packaging tools like pip) to
-#: console-script wrappers. All three are exactly 4 characters long (``.exe``,
-#: ``.bat``, ``.cmd``) so a single ``b[:-4]`` slice strips any of them. Stripping
-#: keeps routing decisions stable across POSIX and Windows installs:
-#: ``C:\\Users\\foo\\Scripts\\jrag.exe`` → ``"jrag"``;
-#: ``...\\java-codebase-rag.exe`` → ``"java-codebase-rag"``.
-_WINDOWS_EXE_SUFFIXES: tuple[str, ...] = (".exe", ".bat", ".cmd")
-
-
-def _invoked_program_name() -> str:
-    """Basename of ``sys.argv[0]`` with a Windows executable suffix stripped.
-
-    Returns the empty string when ``sys.argv`` is empty. Otherwise takes
-    ``os.path.basename(sys.argv[0])`` and, if it ends (case-insensitively) with
-    one of ``.exe`` / ``.bat`` / ``.cmd``, drops the 4-character suffix.
-
-    Shared with :mod:`java_codebase_rag.cli_dispatch` for identity-default
-    routing: both legacy-alias deprecation here and ``jrag``-vs-alias routing
-    there rely on the same canonicalized basename. Without this, Windows builds
-    would route ``jrag.exe --version`` through the wrong parser and never emit
-    the deprecation notice for ``java-codebase-rag.exe``.
-    """
-    argv = sys.argv
-    if not argv:
-        return ""
-    base = os.path.basename(argv[0])
-    if base.lower().endswith(_WINDOWS_EXE_SUFFIXES):
-        return base[:-4]
-    return base
-
-
-def _stderr_is_tty() -> bool:
-    """True iff ``sys.stderr`` reports itself as a TTY.
-
-    Defensive against stderr replacements that omit ``isatty``.
-    """
-    stderr = sys.stderr
-    return hasattr(stderr, "isatty") and stderr.isatty()
-
-
-def _suppressed() -> bool:
-    """True iff the notice should be suppressed."""
-    if os.environ.get("JRAG_NO_DEPRECATION"):
-        return True
-    return not _stderr_is_tty()
-
-
-def maybe_warn_legacy_alias(stream=None) -> None:
-    """Emit a one-line legacy-alias deprecation notice when appropriate.
-
-    Detects a legacy invocation (``sys.argv[0]`` basename is exactly
-    ``java-codebase-rag`` or ``java-codebase-rag-mcp``) and, if not suppressed,
-    writes a single line to ``stream`` (defaulting to ``sys.stderr``). Never
-    raises: any error inside the write is swallowed so the rename helper can
-    never break tool startup.
-
-    See module docstring for the suppression rule.
-    """
-    if _invoked_program_name() not in _LEGACY_ALIASES:
-        return
-    if _suppressed():
-        return
-    target = stream if stream is not None else sys.stderr
-    try:
-        target.write(_DEPRECATION_LINE)
-    except Exception:  # pragma: no cover - defensive: never break startup
-        return

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
-(``jrag-cli`` 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 = "jrag-cli"
-
-
-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()})"