User cannot execute Install (Windows).bat #78

Activity

1. pendingintent

   added this to the release-v0.5 milestone on Sep 9, 2026
2. pendingintent

   self-assigned this

   on Sep 9, 2026
3. pendingintent

   added

   bugSomething isn't workingSomething isn't working

   on Sep 9, 2026
4. pendingintent commented on Sep 9, 2026

   

   pendingintent

   on Sep 9, 2026

   OwnerAuthor

   More actions

   Installation to Windows was successful for another user.
5. pendingintent commented on Sep 9, 2026

   

   pendingintent

   on Sep 9, 2026

   OwnerAuthor

   More actions

   ERROR: Python was not found message only means where py and where python both came back empty when the double-clicked .bat ran — it's not saying Python isn't installed, and the screenshot confirms it clearly is (3.12.10, on PATH, from PowerShell).

   The mismatch is a classic Windows PATH-caching gotcha, not a bug in how the script detects Python:

   • The Python installer's "Add python.exe to PATH" writes the change to the registry, but already-running processes don't see it — including explorer.exe, which is what launches a double-clicked .bat.
   • A PowerShell window can show the updated PATH if it (or the terminal app hosting it) was started after the PATH change propagated, while explorer.exe itself often keeps a stale copy until the user signs out/in or reboots.
   • So: PowerShell says "found," but the .bat — spawned by Explorer's still-stale environment — genuinely can't see python.exe on PATH at that moment. Both results are correct for their respective process's view of PATH.
6. pendingintent commented on Sep 9, 2026

   

   pendingintent

   on Sep 9, 2026

   OwnerAuthor

   More actions

   Installation to Windows was successful for another user.

   This is an environmental issue on the user's computer.
7. pendingintent commented on Sep 9, 2026

   

   pendingintent

   on Sep 9, 2026

   OwnerAuthor

   More actions

   Proposed fix, so this doesn't keep confusing users: when both where checks fail, before showing the generic "Python was not found" error, have the .bat:

   1. Also probe the common per-user/per-machine install locations directly (%LocalAppData%\Programs\Python\Python31x\python.exe, %ProgramFiles%\Python31x\python.exe) as a fallback, in case Python is installed but PATH hasn't propagated to Explorer yet.
   2. If still not found, change the error message to explicitly suggest the real fix: "If you just installed Python, sign out and back in (or restart your PC) so Windows picks up the updated PATH, then try again." — instead of implying Python isn't installed at all.
8. pendingintent commented on Sep 9, 2026

   

   pendingintent

   on Sep 9, 2026

   OwnerAuthor

   More actions

   For the user to fix the issue and continue with the installation:

   1. Reboot the PC (simplest, guaranteed to work) — forces every process, including Explorer, to pick up the updated PATH.
   2. Sign out and back in — same effect as a reboot for this purpose, without a full restart.
   3. Restart Explorer without rebooting — Task Manager → find "Windows Explorer" → Restart. More technical, but avoids losing other open windows/state.
   4. Skip the .bat and run it directly from the PowerShell window that already works: python install.py in that same PowerShell session, from the extracted release folder. Since that shell already resolves python correctly, this sidesteps Explorer's stale environment entirely.
9. pendingintent

   added

   help wantedExtra attention is neededExtra attention is needed

   and removed

   bugSomething isn't workingSomething isn't working

   on Sep 9, 2026
10. pendingintent commented on Sep 9, 2026

    

    pendingintent

    on Sep 9, 2026

    OwnerAuthor

    More actions

    After running python install.py:

    

    I cannot figure out where it created “start.bat”. I even searched the whole app folder for it and nothing came up
11. pendingintent commented on Sep 9, 2026

    

    pendingintent

    on Sep 9, 2026

    OwnerAuthor

    More actions

    Since the installer just finished in that exact PowerShell window, the fastest confirmation is to run this right there:

    dir Start.bat
    

    That tells us definitively whether it's on disk. If it shows the file, the likely explanations for "not seeing it" are:

    1. File Explorer just needs a refresh (F5) — if they had that folder open in Explorer before/during the install, it won't show new files until refreshed.
    2. They're looking in the wrong folder — e.g. Downloads/the original .zip location instead of C:\apps\cdisc-concept-curation_v0.5\ where it was actually extracted and run.
    3. Antivirus quarantined it — worth considering, since Start.bat launches powershell -Command Start-Process ..., a pattern some AV heuristics flag on newly-created .bat files. If dir Start.bat in PowerShell shows nothing despite the install log saying it was created, check Windows Security → Protection history for a removed/quarantined item.

    Run dir Start.bat in that PowerShell window and report what it shows — that'll tell us which of these it is.
12. pendingintent commented on Sep 10, 2026

    

    pendingintent

    on Sep 10, 2026

    OwnerAuthor

    More actions

    User is reporting the Start.bat is missing.

    
13. pendingintent commented on Sep 10, 2026

    

    pendingintent

    on Sep 10, 2026

    OwnerAuthor

    More actions

    Start.bat is missing — .venv, .env, and everything else the installer touches are all present with matching timestamps.

    Combined with the earlier screenshot clearly showing "Created Start.bat" printed successfully, means the file was written and then disappeared afterward.

    Since path.write_text() in install.py would raise a visible Python error if the write itself had failed, this isn't an installer bug — it's almost certainly antivirus/Windows Defender quarantining the file right after it was created.

    Why Start.bat specifically and not the other .bat files in the folder is because the only file written dynamically at runtime by python.exe rather than shipped as a static file in the release archive, and its content (a script that shells out to powershell -Command Start-Process '<url>' to auto-open the browser) is exactly the kind of pattern AV heuristics flag on newly-created scripts — a process writing a .bat that itself launches PowerShell.

    Immediate workaround — skip the launcher and start the app directly in that same PowerShell window:

    .venv\Scripts\activate
    python app.py

    Now open http://localhost:8081 in a browser manually.

    To confirm/recover the quarantined file: Windows Security → Virus & threat protection → Protection history — look for an item around the install time and restore it (or add an exclusion for that folder before re-running the installer).

    This a robustness gap in create_start_launcher() in install.py: swapping the powershell -Command Start-Process call for the plain start "" "http://localhost:%PORT%" cmd builtin would achieve the same auto-open-browser behavior without the PowerShell-spawning pattern that's triggering AV.
14. pendingintent

    modified the milestones: release-v0.5, release-v0.6 on Sep 10, 2026
15. pendingintent

    linked a pull request that will close this issueFix Windows Start.bat quarantined by antivirus #79on Sep 10, 2026
16. pendingintent

    linked a pull request that will close this issueMerge release-v0.7 into main #88on Sep 16, 2026
17. pendingintent

    closed this as completedin #88on Sep 28, 2026