Introduction Hello from Japan! 🇯🇵 I am , a professional truck driver working in logistics while teaching myself Python.
In my previous article, I tested a Docker multi-stage build and measured the actual change in image size.
At the end of that article, I said that I would write next about and CI/CD.
This article was supposed to be the practical follow-up.
However, while preparing for that work, I encountered an unexpected side issue.
I only intended to introduce Flask-Migrate.
Instead, the pip installation logs revealed that the version of a library in my local development environment had been changed without me noticing.
The library was: From there, I went through the following process: Identify the version mismatch Restore the version that had already been tested locally Update Manually verify the Gemini API functionality Run pytest to check for regressions This article records that process without hiding the inconvenient parts. https://github.com/tosane932/sales_data_app Overview While installing Flask-Migrate, I noticed a mismatch between: The version of installed in my local development environment The version declared in The local environment had been using: However, still specified: When I ran: pip followed the configuration file and replaced the newer local version with the older declared version.
This article explains how I discovered the issue, synchronized the environments, and verified the application behavior with automated tests.
1.
The Problem and Its Background I was preparing to introduce Flask-Migrate.
During that work, I ran: The installation log contained the following lines: That message caught my attention.
After checking the environment, I discovered that I had been developing and testing the application locally with: However, still contained the older version: Because pip treats as the declared source of dependency versions, it removed version and installed version .
In other words, my local environment had been unintentionally downgraded.
The application had appeared stable before the installation command, but the dependency configuration and the actual environment were not synchronized.
This created several possible risks: A method available in might not exist in API behavior may differ between versions A production or CI environment could reproduce the older version The local environment might behave differently from deployment A future installation could silently change the application's behavior I therefore decided that I needed to do more than simply reinstall the newer package.
I needed to make the declared configuration and the real environment match exactly.
2.
Investigation and Recovery Process Step 1: Confirm the Installed Version First, I checked the currently installed package.
This command displays information such as: Package name Installed version Installation location Dependencies The log had already shown that version existed before the downgrade, but I wanted to confirm the current state directly.
Step 2: Restore the Previously Tested Version I treated version as the correct version because it was the version I had already used during local development and manual testing.
I reinstalled it explicitly.
Specifying the version made the intended state clear.
Instead of allowing pip to choose a version implicitly, I restored the exact version that had already been tested.
Step 3: Update Restoring the local package was not enough.
If still specified , the same downgrade would happen again in: A clean virtual environment GitHub Actions Docker builds Render deployments Another developer's machine I therefore updated the dependency declaration.
The important point was to align these two states: Without that alignment, the application could behave differently depending on where it was installed.
3.
Manual Application Verification After restoring the package version, I manually tested the application features that use the Gemini API.
I checked the AI-generated advice on: The daily sales input page The dashboard The application used: I confirmed that the AI advice was generated without missing content or unexpected errors.
This manual check was important because dependency installation can succeed even when application-level behavior has changed.
The following command only proves that the package can be installed: It does not prove that: The API client is initialized correctly The model request works The response format is compatible The application still handles the result correctly For that reason, I verified the actual user-facing functionality through the browser.
4.
Verifying the Logic with pytest In addition to manual testing, I ran the prompt-related automated tests that I had already created.
The purpose was to check whether restoring the library version had caused any regression in the existing application logic.
The test suite covered three behaviors: The sales data is included in the generated prompt The required instructions are included The function returns a string The result was: All three tests completed successfully.
This provided an additional level of confirmation that the prompt-generation logic remained intact after the dependency correction.
What the Test Result Proved—and What It Did Not The passing tests confirmed that the behaviors defined in still worked.
However, they did not directly prove that the Gemini API itself was functioning.
The prompt tests check local logic such as: They do not necessarily make a real external API request.
That is why I used both: Manual browser verification for the Gemini API integration pytest for the local prompt-building logic These two checks covered different parts of the system.
A passing unit test should not be treated as proof of every part of the application.
Why the pip Log Was Important The issue was not discovered through an application crash.
It was discovered through the installation log.
The key message was: If I had ignored the output and only checked whether the installation command completed successfully, I might not have noticed that the package had been downgraded.
The installation itself was successful.
The environment change was still unintended.
This taught me that a successful command can still contain important warnings or state changes.
The final line of a command is not the only useful information.
Local Environments Can Hide Configuration Problems My local environment had accumulated packages and versions from earlier development work.
As a result, it had reached a state that was not fully represented by .
The mismatch looked like this: The application could appear to work locally because the newer package was already installed.
However, a clean environment would follow the dependency file and install the older version.
This is the same type of problem behind the phrase: It worked on my machine.
The problem is not always the application code.
Sometimes the undeclared environment itself is the hidden dependency.
Why Exact Version Pinning Helped By writing: I made the intended version explicit.
This improves reproducibility because pip is instructed to install the same version in every environment.
However, exact pinning also creates a maintenance responsibility.
The version will not automatically move to a newer release.
That means I must periodically review: Security updates Deprecation notices API changes Compatibility with the selected Gemini model Changes to transitive dependencies Exact pinning reduces accidental changes.
It does not remove the need for future updates.
A Safer Verification Flow After this incident, I understood the value of the following sequence.
1.
Inspect the Current Environment
2.
Compare It with the Configuration
3.
Install the Intended Version
4.
Update the Dependency File
5.
Verify the Installed State Again
6.
Run Automated Tests
7.
Test the Actual API-Related Feature Open the application and confirm that the Gemini-generated advice still works.
This sequence checks both configuration and behavior.
Result