Yicong-Huang opened a new issue, #7066:
URL: https://github.com/apache/texera/issues/7066

   ### Feature Summary
   
   On a machine that is missing part of the toolchain, `bin/local-dev.sh` prints
   an install hint and exits. A new contributor then hand-installs five or six
   things, re-running `up` after each one to discover the next gap. The script
   already knows how to *find* every tool; it should also be able to *get* them,
   after asking.
   
   Two concrete gaps today:
   
   1. **No offer to install.** `_install_hint` prints a one-line suggestion per
      tool and gives up. Nothing is verified afterwards, so a partial install
      surfaces as the same hint on the next run.
   2. **Python is picked blindly.** `UDF_PYTHON_PATH` defaults to
      `command -v python3` (main.sh ~522). That resolves to the system
      interpreter, which usually has none of `amber/requirements.txt` installed 
—
      so Python UDFs fail at worker launch on a stack of import errors that 
point
      nowhere near the interpreter choice. The venv that AGENTS.md tells
      contributors to create (`<workspace>/venv312`) is ignored, as is an
      already-activated `$VIRTUAL_ENV`.
   
   ### Proposed Solution or Design
   
   **Detect first, and detect the *right* interpreter.** Resolve the Python used
   to launch UDF workers in this order, taking the first candidate that is 3.12
   **and** can import the amber requirements:
   
   ```
   $UDF_PYTHON_PATH (explicit)  ->  $VIRTUAL_ENV/bin/python  ->  
<workspace>/venv312/bin/python
     ->  pyenv 3.12  ->  python3.12 on PATH  ->  python3 on PATH
   ```
   
   Report which one was chosen, the way the JDK probe already reports
   `JAVA_HOME`. A wrong-but-present interpreter should be named as such, not
   silently used.
   
   **Then offer to install what is still missing**, one prompt per tool, default
   "no", and re-verify after each install:
   
   | Tool | Installer | Notes |
   | --- | --- | --- |
   | JDK 17 | distro package manager (`apt`/`dnf`/`pacman`), `brew` on macOS | 
SDKMAN as the no-sudo fallback. `jenv` is only a version *switcher* — it cannot 
install a JDK — so at most `jenv add` the result. |
   | Node 24 | `nvm` | Already the first thing `main.sh` looks for when 
sourcing a version manager. |
   | Python 3.12 | `pyenv` | Pin the default to **3.12**, matching AGENTS.md's 
version table. |
   
   Constraints that matter for keeping the script scriptable:
   
   * **Prompt only on a TTY.** Non-interactive runs (CI, cron, agents) must keep
     today's behaviour exactly: print the hint, exit non-zero. AGENTS.md already
     tells agents to use the non-interactive subcommands.
   * **Explicit flags** so a TTY user can skip the questions in either
     direction — one to accept every install, one to refuse and just print 
hints.
   * **Never `sudo` without saying so.** If the chosen installer needs root, 
show
     the exact command before running it.
   * **Never touch the user's shell rc files silently.** If a version manager
     needs a line in `~/.bashrc`/`~/.zshrc`, print it rather than appending it.
   
   Out of scope: installing docker (needs a daemon, group membership, and a
   re-login) and sbt. Those keep printing hints.
   
   ### Affected Area
   
   Deployment / Infrastructure
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to