Windows und WSL sauber fuer QuantenRam einrichten

Die wichtigste Entscheidung fuer den Alltag lautet deshalb nicht "Windows oder WSL?", sondern "welche Seite ist meine Hauptlaufzeit?" Wenn du Python, virtuelle Umgebungen, Git und API-Tests ueberwiegend in WSL betreibst, sollte dieses Muster konsequent bleiben. Wenn du dagegen bewusst Windows-first arbeitest, solltest du Requests, Variablen und IDE-Interpreter ebenso konsistent auf der Windows-Seite halten. Chaos entsteht fast immer dann, wenn dieselben Befehle halb in PowerShell und halb in Bash weitergereicht werden.

WSL2 fuer Entwicklung einrichten

Wenn WSL2 dein Hauptarbeitsplatz werden soll, beginne mit einer aktuellen Linux-Distribution und halte die Grundwerkzeuge dort sauber. Fuer viele Teams ist Ubuntu unter WSL2 die pragmatischste Wahl, weil Paketverwaltung, Zertifikatspfad und Python-Handling gut dokumentiert sind. Nach der Installation lohnen sich ein frisches Paketupdate und eine getrennte Python-Umgebung pro Projekt, damit Windows- und WSL-Interpreter sich nicht gegenseitig ueberschreiben.

wsl --install -d Ubuntu

sudo apt update
sudo apt install -y python3 python3-venv python3-pip curl ca-certificates

python3 -m venv .venv
source .venv/bin/activate

Damit hast du eine saubere Basis fuer lokale Tests gegen QuantenRam. Wichtig ist, dass die virtuelle Umgebung in WSL lebt und nicht auf einem zufaellig gemounteten Windows-Pfad herumwandert. Das reduziert Probleme mit Dateirechten, Paket-Binaries und Zeilenenden deutlich.

Python-Umgebung in WSL stabil halten

WSL eignet sich besonders gut fuer Python-basierte Integrationen, weil du dort dieselben Grundmuster wie spaeter auf einem Linux-Server nutzen kannst. Das betrifft nicht nur venv, sondern auch Zertifikatsdateien, Environment-Handling und Shell-Skripte. Wenn du ein Projekt langfristig in WSL betreibst, sollte auch dein Editor genau diesen Interpreter verwenden und nicht stillschweigend auf einen globalen Windows-Python zurueckfallen.

python -m pip install --upgrade pip

python - <<'PY'
import json
import os
import urllib.request

payload = json.dumps({
    "model": "quantenram-start/glm-5",
    "messages": [{"role": "user", "content": "Antworte mit ok."}],
}).encode("utf-8")

request = urllib.request.Request(
    "https://quantenram.net/v1/chat/completions",
    data=payload,
    headers={
        "Authorization": f"Bearer {os.environ['QUANTENRAM_API_KEY']}",
        "Content-Type": "application/json",
    },
)

with urllib.request.urlopen(request) as response:
    body = json.load(response)

print(body["choices"][0]["message"]["content"])
PY

Wenn dieser Test in WSL funktioniert, in Windows aber nicht, ist das ein starkes Signal fuer Shell-, Proxy- oder Zertifikatsunterschiede und nicht fuer ein generelles API-Problem. Genau darum lohnt sich WSL-first oft auch dann, wenn das restliche Team unter Windows arbeitet.

API-Key-Management unter Windows und in WSL getrennt denken

API-Keys sind immer an die Prozessumgebung gebunden, in der dein Request startet. Ein Key, den du in ~/.bashrc exportiert hast, existiert nicht automatisch in PowerShell. Ebenso sieht eine Windows-Anwendung keine WSL-Variable, solange du sie nicht bewusst weiterreichst. Wer beides parallel nutzt, sollte deshalb nicht hoffen, sondern pruefen.

export QUANTENRAM_API_KEY="qr_xxxxxxxxx"
printenv QUANTENRAM_API_KEY

$env:QUANTENRAM_API_KEY = "qr_xxxxxxxxx"
$env:QUANTENRAM_API_KEY

[System.Environment]::SetEnvironmentVariable(
  "QUANTENRAM_API_KEY",
  "qr_xxxxxxxxx",
  "User"
)

Fuer den Alltag heisst das: Setze den Key in der Shell, in der du wirklich testest. Fuer persistente Konfiguration kannst du ihn auf Windows-Seite im Benutzerkontext hinterlegen und auf WSL-Seite in die Shell-Initialisierung aufnehmen. Fuer Team- oder Produktionsgeraete bleibt ein geordnetes Secret-Management natuerlich sinnvoller als das manuelle Herumtragen von Klartextwerten.

Typische Windows-spezifische Fehlerbilder

Der bekannteste Stolperstein ist das Zusammenspiel von PowerShell und curl. In vielen Windows-Setups zeigt curl nicht auf das erwartete native Programm, sondern auf ein PowerShell-Alias. Wenn JSON-Requests ploetzlich seltsam gequotet werden oder Header anders interpretiert wirken, sollte der Test mit curl.exe wiederholt werden. Dadurch trennst du echte API-Probleme von Shell-Eigenheiten.

curl.exe https://quantenram.net/v1/models `
  -H "Authorization: Bearer $env:QUANTENRAM_API_KEY"

Ein zweites typisches Thema sind CRLF- und LF-Unterschiede. JSON-Dateien, Shell-Skripte oder kleine Payload-Dateien funktionieren in WSL am ruhigsten mit LF. Wenn eine unter Windows bearbeitete Datei in WSL ploetzlich Parsing-Fehler ausloest, lohnt sich ein Blick auf Zeilenenden oft mehr als jede API-Spekulation. Dasselbe gilt fuer Pfade: C:\Users\... und /mnt/c/Users/... sehen verwandt aus, sind aber nicht dieselbe Ausfuehrungsrealitaet.

Auch Zertifikate koennen auf Windows und WSL unterschiedlich bewertet werden. Ein Unternehmenszertifikat, das im Windows-Zertifikatsspeicher bereits vertraut ist, liegt in WSL nicht automatisch vor. Wenn also Browser und PowerShell funktionieren, WSL-curl aber ueber TLS klagt, fehlt haeufig nicht das Netzwerk, sondern das passende Root-Zertifikat im Linux-Trust-Store.

Integration mit Windows-IDEs

Moderne IDEs koennen sehr gut mit einem WSL-Interpreter arbeiten, auch wenn die Anwendung optisch auf Windows laeuft. Genau das ist fuer viele Teams die beste Mischung: Editor, Fensterverwaltung und GUI bleiben nativ, waehrend Terminal, Python, Git und API-Tests in WSL laufen. Damit vermeidest du viele Cross-OS-Unterschiede, ohne auf gewohnte Windows-Werkzeuge zu verzichten.

Wichtig ist dabei, dass die IDE nicht versehentlich auf einen anderen Interpreter umspringt. Wenn dein Projekt in WSL entwickelt wird, sollte auch der Projektinterpreter dort liegen, die virtuelle Umgebung dort erstellt werden und das Terminal der IDE denselben Kontext benutzen. Sobald Windows-Interpreter und WSL-Terminal gemischt werden, werden Fehler schwerer reproduzierbar und Support-Tickets unnoetig unklar.

API-Calls von Windows und WSL gegeneinander testen

Der schnellste Stabilitaetstest fuer gemischte Umgebungen besteht darin, denselben Minimalrequest einmal in WSL und einmal in PowerShell auszufuehren. Wenn beide denselben Status und dieselbe Modellliste liefern, ist dein Setup meist sauber genug fuer produktive Arbeit. Wenn nur eine Seite funktioniert, ist die Abweichung sehr wahrscheinlich in Shell, Proxy, Zertifikaten oder Umgebungsvariablen zu finden.

curl https://quantenram.net/v1/models \
  -H "Authorization: Bearer $QUANTENRAM_API_KEY"

curl.exe https://quantenram.net/v1/models `
  -H "Authorization: Bearer $env:QUANTENRAM_API_KEY"

Fuer Chat-Requests lohnt es sich bei Windows besonders, Payload-Dateien statt inline JSON zu verwenden. Damit vermeidest du die meisten Quoting-Probleme sofort. Gleichzeitig kannst du dieselbe Datei in WSL und Windows testen und pruefen, ob wirklich dieselben Inhalte ueber die Leitung gehen. Genau solche kleinen Vereinheitlichungen machen ein gemischtes Setup betrieblich ruhig.