Fix Windows DLL

[t0mdavid-m]

Summary by CodeRabbit

• Chores
  • Optimized Windows executable packaging by removing an unnecessary bundled DLL to reduce bundle size and avoid potential runtime conflicts.
  • Adjusted the build environment to install a constrained pip version earlier in the process, improving installation reproducibility and stability for subsequent package installs.

[coderabbitai]

Walkthrough

Updates to CI/build configuration: the Windows packaging workflow now removes streamlit_exe/userenv.dll from the assembled bundle, and the Dockerfile adds an early mamba step to install pip<25 before other Python package installs.

Changes

Cohort / File(s)	Change Summary
Windows Build Workflow .github/workflows/build-windows-executable-app.yaml	Adds a deletion step to remove streamlit_exe/userenv.dll during the Windows packaging/bundle assembly.
Container build Dockerfile	Adds a mamba command to install pip<25 prior to other Python package installations, ensuring the constrained pip is present before subsequent installs.

Sequence Diagram(s)

sequenceDiagram
    autonumber
    participant DevOps as CI runner
    participant Packager as Windows packager
    participant Bundle as Assembled bundle
    Note right of DevOps `#b3e2cd`: New pre-install step in Dockerfile
    DevOps->>DevOps: mamba install pip<25
    DevOps->>Packager: run build steps
    Packager->>Bundle: assemble bundle files
    Note right of Packager `#ffe6cc`: New cleanup step
    Packager->>Bundle: delete "streamlit_exe/userenv.dll"
    Packager->>DevOps: produce final artifact

Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Small number of CI/container config edits.
• Review attention recommended for:
  • .github/workflows/build-windows-executable-app.yaml — confirm deletion timing and artifact paths.
  • Dockerfile — ensure mamba is available in base image and pip constraint doesn't break downstream installs.

Possibly related PRs

• switch to powershell #52 — modifies the same Windows CI workflow file; likely related to Windows packaging or artifact adjustments.

Poem

🐰 I hopped through build and Dockerfile light,
I nudged pip down to keep installs right,
I plucked one DLL from the Windows tree,
Now bundles are tidy — hooray from me! 🥕

Pre-merge checks and finishing touches

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'Fix Windows DLL' is specific to the main change in the .github/workflows/build-windows-executable-app.yaml file, which removes streamlit_exe/userenv.dll from the Windows package bundle.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix_windows_dll_error

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d393099 and 2f32065.

📒 Files selected for processing (1)

• Dockerfile (1 hunks)

🧰 Additional context used

🪛 Hadolint (2.14.0)

Dockerfile

[error] 82-82: Ensure the shebang uses an absolute path to the interpreter.

(SC2239)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

• GitHub Check: build-openms
• GitHub Check: build-full-app

🔇 Additional comments (2)

Dockerfile (2)

82-82: Hadolint static analysis flag appears to be a false positive.

The Hadolint error "Ensure the shebang uses an absolute path to the interpreter" (SC2239) does not apply to this RUN directive—it references shell script shebangs, not Docker instructions. This can be safely ignored.

---

82-84: Verify the pip version constraint is appropriate for the dependency ecosystem.

NumPy 1.26 moved to a Meson build system, required by Python 3.12's removal of distutils, and supports both Cython 3.0 and 0.29.x compatibility—aligning well with the Cython<3.1 constraint on line 84. The pip<25 constraint is justified: pip 25+ introduces build-system changes with new dependencies and PEP 517 enforcement, which can cause C-extension build failures on Windows when strict build isolation encounters incompatibilities with older setuptools/distutils configurations. Pinning to pip<25 ensures compatibility with numpy==1.26.4 and avoids these Windows build isolation issues.

Ensure the Dockerfile or referenced build-system (if any) declares build-time dependencies explicitly, as this may be relevant for pip 24.x+ compliance.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

.github/workflows/build-windows-executable-app.yaml (1)

310-311: Add a comment explaining why userenv.dll is removed.

The fix is correct—userenv.dll is a Windows system DLL that shouldn't be bundled with the application. However, the removal lacks any explanation, making it unclear to future maintainers why this step is necessary.

Add a comment to document the rationale:

  cp openms-bin/*.dll streamlit_exe
+ # Remove Windows system DLLs that conflict with bundled dependencies
+ # userenv.dll is provided by Windows and should not be shipped with the app
  rm streamlit_exe/userenv.dll

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 2a74955 and d393099.

📒 Files selected for processing (1)

• .github/workflows/build-windows-executable-app.yaml (1 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

• GitHub Check: build-openms
• GitHub Check: build-full-app