NLTK 3.10 is acting weird in venvs

[HendrikStrobelt]

Issue

• mellea/init.py → … → rouge_score → nltk 3.10.1
• nltk 3.10.1 ships a new import hook (nltk/inisec.py) that blocks any import whose
  resolved path lies under Path.cwd()
• Your .venv lives inside the project root, so .venv/…/site-packages/regex is "under
  cwd" → blocked

So the hook misfires for every in-tree virtualenv. The error message's advice is a red
herring: I verified PYTHONSAFEPATH=1 does not fix it (the check is on the module's
file path, not on sys.path), while NLTK_DISABLE_IMPORT_SECURITY=1 does:

NLTK_DISABLE_IMPORT_SECURITY=1 .venv/bin/python -c "import nltk" → ok 3.10.1

Also note the secondary side effect: inisec._install() does
os.environ.setdefault("PYTHONSAFEPATH", "1"), which leaks into any subprocess the
proxy spawns.

possible solves

1. Set the env var in code
   Set NLTK_DISABLE_IMPORT_SECURITY=1 (via os.environ.setdefault, so users can
   override) before the first mellea import — in one shared helper used by all 4
   mellea import sites. Keeps nltk current, no dependency-graph changes, works for uv run, pytest, and direct .venv/bin/mellea-proxy alike.

2. Pin nltk<3.10
   Add nltk>=3.9,<3.10 to the [mellea] extra so the hook-free 3.9.x is resolved.
   mellea only requires nltk>=3.9 so this resolves cleanly, but it holds back a
   transitive dep and needs a uv.lock update.

AI was used to identify bug and propose solves

[planetf1]

• The inisec.py import hook is only present in nltk 3.10.1; it is absent in 3.9.x, 3.10.0, and 3.10.2+.
• NLTK removed the hook entirely in 3.10.2 (5 Aug) via nltk/nltk#3732.
• The env var workaround (NLTK_DISABLE_IMPORT_SECURITY=1) disables the hook process-wide, which may weaken security for other libraries sharing the interpreter.
• nltk<3.10 is overly broad and blocks the fixed 3.10.2 release.
• Recommendation: Update pyproject.toml to "nltk>=3.9,!=3.10.1". This excludes only the single broken release, lets the lockfile pick up the fixed 3.10.2 on refresh, and requires no mellea source code changes.
• Verified via uv lock that !=3.10.1 resolves cleanly to 3.9.4 or 3.10.2 without dependency conflicts.

[HendrikStrobelt]

Great find. Agreed.