Windows integrated package: users.pth contains the packager's absolute paths, silently disabling all sys.path injection

Summary

In the Windows integrated package (GPT-SoVITS-v2pro-20250604.7z, currently hosted on lj1995/GPT-SoVITS-windows-package), the file

runtime/lib/site-packages/users.pth

contains hardcoded absolute paths from the packager's own machine:

D:\BaiduNetdiskDownload\GPT-SoVITS-v2-240821b\GPT-SoVITS-v2pro-20250604
D:\BaiduNetdiskDownload\GPT-SoVITS-v2-240821b\GPT-SoVITS-v2pro-20250604/GPT_SoVITS/BigVGAN
D:\BaiduNetdiskDownload\GPT-SoVITS-v2-240821b\GPT-SoVITS-v2pro-20250604/tools
D:\BaiduNetdiskDownload\GPT-SoVITS-v2-240821b\GPT-SoVITS-v2pro-20250604/tools/asr
D:\BaiduNetdiskDownload\GPT-SoVITS-v2-240821b\GPT-SoVITS-v2pro-20250604/GPT_SoVITS
D:\BaiduNetdiskDownload\GPT-SoVITS-v2-240821b\GPT-SoVITS-v2pro-20250604/tools/uvr5

Unless a user happens to extract to that exact path, all six sys.path entries resolve to nonexistent directories and contribute nothing.

In my extracted copy the file's mtime (2025-11-11) predates my download by months, so it was baked in at packaging time rather than created locally.

Why this is hard to diagnose

The failure is silent — site.py skips nonexistent paths without any warning. The visible symptom is ModuleNotFoundError: No module named 'tools' (or text, tools.my_utils, tools.i18n) from anything launched as a subprocess, e.g.:

runtime\python.exe -s tools/asr/fasterwhisper_asr.py ...
runtime\python.exe -s GPT_SoVITS/prepare_datasets/1-get-text.py

Two things make it worse:

• runtime/python39._pth is an embedded-distribution config, so PYTHONPATH is ignored — users cannot work around it from the environment.
• go-webui.bat launches with -I (isolated mode), which also ignores PYTHONPATH.

I suspect this is the root cause of #1496 (open since 2024-08, no diagnosis), which reports exactly this error when using UVR5 / audio slicing in the Windows package.

Reproduce

Extract the package anywhere other than the packager's original path, then:

runtime\python.exe -c "import tools.my_utils"
# ModuleNotFoundError: No module named 'tools'

Suggested fix

.pth lines beginning with import are executed by site.addpackage, and the site-packages directory is available as sitedir in the calling frame. So users.pth can locate the project root itself, with no packaging-time path baked in:

import os,sys; _r=os.path.dirname(os.path.dirname(os.path.dirname(sys._getframe(1).f_locals['sitedir']))); sys.path += [_r, os.path.join(_r,'GPT_SoVITS','BigVGAN'), os.path.join(_r,'tools'), os.path.join(_r,'tools','asr'), os.path.join(_r,'GPT_SoVITS'), os.path.join(_r,'tools','uvr5')]

(site-packages → lib → runtime → project root, hence three dirname calls. The same sys._getframe(1).f_locals['sitedir'] idiom is already used by matplotlib-*-nspkg.pth and google_auth-*-nspkg.pth shipped in that same directory.)

One caveat for whoever applies this: do not use a list comprehension or a lambda in that line. site.addpackage runs it via exec(line) with separate globals and locals, and a comprehension opens a new scope that cannot see _r, producing NameError: name '_r' is not defined. Plain expressions work.

Verification

Tested on Windows 11 with the v2pro-20250604 package. After replacing users.pth with the line above, import tools.my_utils and import text.cleaner both succeed, and CLI invocation of the ASR script and the prepare_datasets scripts works with no PYTHONPATH juggling.