Separate installers for WSR and DNS

[kendonB]

From GPT 5.2 Thinking XHigh:

Is your feature request related to a problem? Please describe.
Windows installs are currently fragile because WSR and DNS/Natlink have different interpreter/bitness constraints, but the install flow doesn’t make this explicit.

Users can hit “can’t install wheels / no matching distribution” errors (e.g., regex, wxpython, Qt
bindings) and version mismatches, especially on Python 3.12. The existing .bat flow also assumes the python.org py launcher is present, which fails on many Conda-based setups.

Describe the solution you'd like
Provide an explicit, modern Windows install experience that supports Python 3.12 and clearly separates WSR vs DNS:

• Add two engine-specific installers:
  • Install_Caster_WSR.bat: targets Python 3.12+ (recommend 64-bit), creates/uses a local venv, upgrades pip tooling, installs a pinned WSR dependency set, and verifies imports/launch.
  • Install_Caster_DNS.bat: targets the Natlink-managed Python environment, installs a pinned DNS dependency set, and verifies Natlink/dragonfly integration.
    (Alternatively: one installer script with --engine wsr|dns plus two thin wrappers.)
• Split dependencies by engine so installs are deterministic and don’t pull unrelated packages:
  • e.g., requirements-wsr.txt and requirements-dns.txt (or equivalent extras/lockfiles).
• Ensure Python 3.12, 3.13, 3.14 compatibility across required dependencies (notably Qt bindings; avoid dependencies that don’t provide wheels).
• Add preflight checks with clear output and failure messages:
  • detected interpreter path, Python version, 32/64-bit, presence/absence of py launcher,
  • actionable guidance when the environment is unsupported.

Describe alternatives you've considered

• Keep a single combined Install_Caster_DNS-WSR.bat and add more branching/detection (still opaque and hard to debug).

Additional context

• Issue Can't install on w10 with the WSR bat file. output says it cant install wheels for regex and wxpthon #948: users reported WSR install failures due to wheel install problems (e.g., regex/wxpython) and Python 3.12 breakages.

[LexiconCode]

I'm in agreement. In an ideal world the be a user install of UV. UV would handle Python install and packages. It will work out of the box for everything but Natlink. I actually have been working with natlink in a python virtual install but I'm waiting on some improvements Dane until I can integrate my work.

So as an intermediate step should we include UV for everything but Natlink and update the documentation and scripts?

[kendonB]

I'm quite comfortable requiring uv for fresh installs (it seems very popular now). Should we do that?

[LexiconCode]

Yes I think that's a good plan!

[drmfinlay]

@LexiconCode, not sure what you're referring to above... Are you still waiting on something from me?

[LexiconCode]

@LexiconCode, not sure what you're referring to above... Are you still waiting on something from me?

No, I'm working on overhauling natlink 64-bit, which will drastically simplify this process. If we get to own the Python environment, everything is a lot easier to manage. The project would simply be able to use a virtual environment.

[drmfinlay]

Ah, okay then, I figured that. I'll see about making some progress on a new Dragonfly release.