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