Impact Acquire Python – Customer-Ready Packaging (Wheels statt Kompilieren)

1. Projektziel

Einfacher Start: Installation in Minuten statt Stunden
Kompatibilität: definierte Python-/OS-Matrix (z.B. Python 3.8–3.12, Win/Linux)
Qualität: Tests pro Wheel (Import + Minimal-API)
IT-friendly: Nutzung ohne Admin-Rechte (wo möglich)
Weniger Support: reproduzierbare Builds + klare Diagnose

2. Pain Points – Was heute Kunden blockiert

Windows

MSVC / PATH / Admin

Compiler-Matching: Python-Version ↔ MSVC Toolset muss passen
PATH-Abhängigkeit: compileWrapperCode.bat findet Python über PATH
Admin-Rechte: je nach Install-Pfad kann „Run as administrator“ nötig sein
Anaconda Legacy: egg-Layout / manuelle Fixes (bei alten Versionen)

Folge: nicht reproduzierbar, viele Support-Tickets.

Linux

Headers / sudo / Distro

python-dev nötig: ohne Headers kein Build
Root nötig: Script installiert in systemweite site-packages
Package-Manager Konflikte: pip kann Module nicht automatisch installieren
Ressourcen: großer SWIG-Wrapper → Memory-Probleme auf Embedded/32-bit

Folge: lange Builds, fragile Umgebungen.

Root Cause: Der Wrapper ist ein binäres Extension-Modul (.pyd/.so) und muss zur Python-Version passen. Aktuell wird der Build auf die Kundenmaschine verlagert.

3. Zielbild – Wheels statt lokaler Kompilierung

Heute

Customer-Build

SDK installieren
Compiler/Headers/Tools installieren
Build-Skript ausführen
Install in systemweite site-packages

Ziel

Prebuilt Wheels

Build in kontrollierter Umgebung (Team/CI oder Skripte)
Wheel pro Python-Version/OS
pytest Smoke Tests pro Wheel
Kunde: pip install … → import …

Erfolg: Kunden benötigen weder Compiler noch sudo/Admin-Rechte, um die Python API zu nutzen.

4. Architekturübersicht

Inputs kommen aus dem SDK-Installationsverzeichnis (LanguageBindings/Python). Outputs sind versionierte Wheels + Test-Reports.

5. Ablauf – Was ich konkret mache

VM Setup (Customer-Like)

Frische Windows-VM: SDK installieren, Doku folgen, Pain Points dokumentieren
Optional Linux-VM: gleiche Validierung

Build verstehen & stabilisieren

compileWrapperCode.* analysieren (Inputs/Outputs)
Python-Interpreter explizit machen (nicht nur PATH)
Ergebnis: .pyd/.so verlässlich erzeugen

Wheel bauen & versionieren

Artefakte sammeln (Python + Extension)
Wheel pro Ziel (cp38…cp312, win_amd64, linux)
Release-Version an SDK-Version koppeln

pytest Smoke Tests

import Test
Minimaler API-Call
Optional Hardware-Test

Doku & Übergabe

Quickstart für Kunden
Troubleshooting (DLL/so path, Treiber)
Build-HowTo fürs Team (kein SPOF)

6. Deliverables

Customer Deliverables

Wheels pro Python/OS
Quickstart + Beispiele
Installation ohne Admin, wo möglich

Team Deliverables

Build-Skripte (reproduzierbar)
pytest Suite
Release Checklist

Beispiel: Customer Happy Path

# Installation
pip install impact_acquire-<VERSION>-cp311-cp311-win_amd64.whl

# Quick sanity check
python -c "import impact_acquire as ia; print('OK')"

Outcome: Keine lokalen Compiler/Headers/sudo mehr beim Kunden → weniger Reibung & Support.

Zurück nach oben