EIM-330 Installer should no longer attempt to download constrainfile during offline installation

[Hahihula]

this should fix bug reported in #245

[gemini-code-assist]

Summary of Changes

Hello @Hahihula, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request resolves a critical bug where the installer would attempt to download constraint files even when performing an offline installation. The core of the fix involves refactoring the Python environment setup. The setup_tools function has been enhanced to accept an optional offline archive directory, ensuring that during offline installations, Python dependencies are sourced locally rather than triggering network requests. This improves the robustness and reliability of the offline installation feature.

Highlights

• Refactored Python Environment Setup: The logic for installing the Python environment has been consolidated and moved into the setup_tools function, streamlining the installation process.
• Offline Archive Directory Parameter: The setup_tools function now accepts an optional offline_archive_dir parameter, allowing it to correctly utilize local archives during offline installations.
• Bug Fix for Offline Installation: This change prevents the installer from attempting to download constraint files during offline installations, directly addressing the bug reported in Offline Installation Fails on Windows Due to Network Dependency (EIM-330) #245.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request refactors the offline installation process to avoid downloading the constraints file, which fixes the reported bug. The change correctly passes the offline archive directory to the tool setup function. It also removes duplicated code for Python environment installation by centralizing it within the setup_tools function.

While the code deduplication is a good improvement, I've pointed out a side-effect on the progress reporting for multi-version offline installations. The hardcoded progress percentages in setup_tools will lead to an incorrect and confusing progress bar for the user. I've suggested a way to make the progress reporting relative to fix this.

Overall, the change is in the right direction, and with the suggested improvement to progress reporting, it will be a solid contribution.

[gemini-code-assist]

This refactoring is a good step towards removing duplicated code. However, by moving the Python environment setup into setup_tools, the progress reporting for offline installations is now incorrect.

The setup_tools function uses hardcoded percentage values for progress updates (e.g., 65% for tools, 90% for Python). When setup_tools is called inside a loop for multiple versions in start_offline_installation, this will cause the progress bar to jump back to these hardcoded values for each version, providing a confusing user experience.

The original code, although duplicated, had logic to calculate progress relative to the overall installation of multiple versions.

To fix this, you could consider making the progress reporting in setup_tools relative. This could be done by passing progress_base and progress_range as arguments to setup_tools and calculating all internal progress percentages based on these values. This would require updating all call sites of setup_tools but would result in a more robust progress reporting mechanism for all installation types.

[Fabricio-ESP]

Confirmed this step is now working.