← Вакансії

Python Windows Desktop App: PyQt6 + SQLCipher Concurrency Skeleton

Бюджет: $200.0 FIXED / ⭐ 0.00 (0) United States

qt, desktop-applications, sqlite, python

Title Python Desktop Skeleton (PyQt6 + SQLCipher, WAL, Single-Writer Queue) — Bulletproof Foundation for a Scaling Sales App Job Description I need a structural skeleton, not a demo. This is a small fixed-price project ($150–$250) precisely because the scope is narrow — but I will be building real production features directly on top of this code for months afterward, so the foundation has to be genuinely correct under the three failure modes below, not just superficially working on your dev machine. I am not paying for a "Hello World" that happens to run once during the interview. I'm paying for proof that three specific, well-known Python-desktop-app failure classes have been engineered out, with evidence I can independently verify. Read the Acceptance Criteria section carefully before applying — I will test against it literally. What You're Building A minimal desktop app: a PyQt6 system tray utility that listens for a global hotkey, reads one row from an encrypted local SQLite (SQLCipher) database through a single-writer background queue, and slides open a small frameless window showing Hello, [Name]!. Trivial on the surface — the value I'm paying for is the plumbing underneath it being correct. Deliverables 1. Encrypted database layer (WAL mode) • Local SQLite database encrypted at rest via SQLCipher (not plain SQLite with a wrapper — actual SQLCipher). • Connection explicitly opens in WAL (Write-Ahead Logging) journal mode. • One table: contacts (name, email). • Seed script that inserts at least one row on first run. 2. Single-writer priority queue • All database writes — regardless of origin thread — are routed through exactly one dedicated writer thread via an in-memory queue. No component is permitted to open its own write connection to the DB file. • The queue must be priority-aware with two lanes, not a flat FIFO: a high-priority lane for UI-originated writes, and a bulk lane for simulated background writes. The worker drains high-priority first and yields between bulk-lane chunks so a UI write is never blocked more than one chunk behind a bulk job. • Include a synthetic load-test script that enqueues a 5,000-row bulk-insert batch (chunked, not one giant transaction) on the bulk lane, then immediately enqueues a single high-priority write and measures its completion latency. This is not decoration — it's the actual mechanism I'm paying for. 3. frontend.py — tray utility • Runs as a minimal PyQt6 background process (system tray icon, no visible main window at idle). • Registers a global Windows hotkey (default Ctrl+Alt+H), functional even when the app is not focused. 4. The Action Window • On hotkey trigger: a small frameless window slides in from the right edge of the screen (not just appears — an actual slide/animate transition). • Reads the seeded row through the writer-thread queue's read path and displays Hello, [Name]!. • Esc closes/slides the window back out. 5. main.py • Wires the tray utility, the hotkey listener, and the database queue together into one running application. 6. License-Tier Gate (single source of truth) • This skeleton will later gate real feature sets (base vs. upgrade) behind a license tier. Build that hook now, not as a retrofit later. • A single license_tier value, checked exactly once at module init (e.g. a small LicenseContext object constructed at app startup and passed down), not scattered if licensed: checks sprinkled through individual modules. • Demonstrate the pattern concretely: gate the Hello, [Name]! Action Window behind a base tier check, and add one placeholder Tier-2-only feature (a stub menu item is fine — no real functionality needed) that only appears/initializes when license_tier == "premium". The point is proving the gating pattern works end-to-end, not building real premium features. • For local development/testing, the tier value can be read from a simple local config/env value — no need to build the actual Cloudflare license-check endpoint for this skeleton. Critical Compilation Deliverable — The Onedir Recipe This is not optional documentation-as-afterthought. It is a deliverable with its own acceptance test (see below). • A step-by-step Markdown or PDF guide covering: clean venv setup, compiling/vendoring the correct SQLCipher binary for the target Python version, and packaging via PyInstaller in --onedir mode (explicitly not --onefile). • The guide must include the actual .spec file used, with an explicit binaries=[] override pinning the SQLCipher DLL by path — not reliance on PyInstaller's automatic dependency walker, which is the exact mechanism that silently grabs the wrong system sqlite3.dll instead of the SQLCipher-capable one. • The guide must include a verification step: running the compiled onedir output through a DLL-inspection tool (e.g. Dependency Walker, lief, or equivalent) and confirming in writing which sqlite3/sqlcipher DLL actually loaded at runtime, with the tool's output pasted into the doc as evidence — not just "it worked for me." Acceptance Criteria (I will test these myself — build to pass them, not to look done) • [ ] DLL isolation proof: I install a decoy sqlite3.dll on my own clean Windows 11 test VM (simulating a stray Anaconda/DB Browser install) and run your compiled onedir build. It must still load the correct SQLCipher-capable driver, verified via DLL inspection, not the decoy. • [ ] Contention proof: I run your load-test script. The high-priority write must complete in under ~50ms of enqueue time even while the 5,000-row bulk batch is actively writing. You provide the timing numbers; I re-run it myself. • [ ] Cold-machine proof: The compiled onedir folder runs correctly on a bare Windows 11 VM with no Python, no Visual C++ redistributables beyond what you explicitly document as a prerequisite, and no dev tools installed. • [ ] No direct-write bypass: Code review confirms zero code paths open a write connection to the SQLite file outside the single writer thread — including the seed script and any test/debug code left in the deliverable. • [ ] WAL confirmed, not assumed: A query against PRAGMA journal_mode at runtime returns wal, captured in your test evidence. • [ ] Single-source license gating: Code review confirms license_tier is read/constructed in exactly one place at startup and passed down (dependency injection, context object, or equivalent) — not re-read or re-checked ad hoc inside individual feature modules. Flipping the local tier value from base to premium and restarting the app is the only thing required to reveal the placeholder Tier-2 stub feature; no code changes needed to demonstrate the toggle. Screening Questions (please answer in your application — generic proposals will be skipped) 1. In one or two sentences: why does PyInstaller's automatic dependency detection sometimes bundle the wrong sqlite3.dll when SQLCipher is also present on the build machine, and what's the direct fix (not "use a venv" — that alone doesn't solve it)? 2. WAL mode solves reader/writer contention, but a single-writer queue can still stutter the UI under load. What's the actual mechanism that prevents that, and why doesn't WAL alone fix it? 3. Have you shipped a PyInstaller --onedir build that was verified to run on a genuinely clean Windows machine (not just a fresh venv on your own dev box)? Briefly describe how you verified it. 4. What's your estimated timeline and how would you split the fixed price across the three deliverable phases (DB/queue layer, PyQt6 shell, compilation docs)? 5. This app will eventually gate a paid "upgrade" feature set behind a license tier. Briefly describe how you'd structure that check so that adding real premium features later doesn't require touching the licensing logic itself. Budget & Scope Fixed price. This is intentionally a small, bounded skeleton — I'm not asking for sales features, Graph API integration, or anything beyond the plumbing above. Scope creep in either direction (over-building or under-delivering the concurrency/DLL guarantees) is a mismatch; please apply only if the scope as written is a comfortable fit. Please apply only if you have direct, provable experience with: PyQt6 desktop layout and animation, Windows global hotkey registration, SQLCipher + SQLite thread/connection management, and compiling directory-mode PyInstaller builds with explicit binary path overrides.
Відкрити на Upwork