DEV Community

Cover image for 🐍 Fixing a `google-genai` Version Mismatch and Verifying the Behavior with pytest [1/3]
tosane932
tosane932

Posted on

🐍 Fixing a `google-genai` Version Mismatch and Verifying the Behavior with pytest [1/3]

#python #flask #pytest #gemini

Introduction

Hello from Japan! 🇯🇵

I am tosane932, 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 pytest 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:

google-genai
Enter fullscreen mode Exit fullscreen mode

From there, I went through the following process:

  1. Identify the version mismatch
  2. Restore the version that had already been tested locally
  3. Update requirements.txt
  4. Manually verify the Gemini API functionality
  5. 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 google-genai installed in my local development environment
  • The version declared in requirements.txt

The local environment had been using:

google-genai 2.10.0
Enter fullscreen mode Exit fullscreen mode

However, requirements.txt still specified:

google-genai==2.4.0
Enter fullscreen mode Exit fullscreen mode

When I ran:

pip install -r requirements.txt
Enter fullscreen mode Exit fullscreen mode

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:

pip install -r requirements.txt
Enter fullscreen mode Exit fullscreen mode

The installation log contained the following lines:

Attempting uninstall: google-genai
    Found existing installation: google-genai 2.10.0
    Uninstalling google-genai-2.10.0:
Enter fullscreen mode Exit fullscreen mode

That message caught my attention.

After checking the environment, I discovered that I had been developing and testing the application locally with:

google-genai 2.10.0
Enter fullscreen mode Exit fullscreen mode

However, requirements.txt still contained the older version:

google-genai==2.4.0
Enter fullscreen mode Exit fullscreen mode

Because pip treats requirements.txt as the declared source of dependency versions, it removed version 2.10.0 and installed version 2.4.0.

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 2.10.0 might not exist in 2.4.0
  • 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.

pip show google-genai
Enter fullscreen mode Exit fullscreen mode

This command displays information such as:

  • Package name
  • Installed version
  • Installation location
  • Dependencies

The log had already shown that version 2.10.0 existed before the downgrade, but I wanted to confirm the current state directly.

Step 2: Restore the Previously Tested Version

I treated version 2.10.0 as the correct version because it was the version I had already used during local development and manual testing.

I reinstalled it explicitly.

pip install google-genai==2.10.0
Enter fullscreen mode Exit fullscreen mode

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 requirements.txt

Restoring the local package was not enough.

If requirements.txt still specified 2.4.0, 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.

google-genai==2.10.0
Enter fullscreen mode Exit fullscreen mode

The important point was to align these two states:

Actual local environment
=
Declared dependency configuration
Enter fullscreen mode Exit fullscreen mode

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:

gemini-2.5-flash
Enter fullscreen mode Exit fullscreen mode

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:

pip install google-genai==2.10.0
Enter fullscreen mode Exit fullscreen mode

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.

pytest test_prompts.py -v
Enter fullscreen mode Exit fullscreen mode

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:

  1. The sales data is included in the generated prompt
  2. The required instructions are included
  3. The function returns a string

The result was:

3 passed
Enter fullscreen mode Exit fullscreen mode

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 test_prompts.py still worked.

However, they did not directly prove that the Gemini API itself was functioning.

The prompt tests check local logic such as:

result = build_sales_prompt("Test data")
assert isinstance(result, str)
Enter fullscreen mode Exit fullscreen mode

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.

Manual verification
→ External API integration and visible application behavior
Enter fullscreen mode Exit fullscreen mode 
pytest
→ Local logic and expected output structure
Enter fullscreen mode Exit fullscreen mode

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:

Attempting uninstall: google-genai
Enter fullscreen mode Exit fullscreen mode

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 requirements.txt.

The mismatch looked like this:

Local environment:
google-genai 2.10.0
Enter fullscreen mode Exit fullscreen mode 
requirements.txt:
google-genai 2.4.0
Enter fullscreen mode Exit fullscreen mode

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:

google-genai==2.10.0
Enter fullscreen mode Exit fullscreen mode

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 

pip show google-genai
Enter fullscreen mode Exit fullscreen mode

2. Compare It with the Configuration 

grep "google-genai" requirements.txt
Enter fullscreen mode Exit fullscreen mode

3. Install the Intended Version 

pip install google-genai==2.10.0
Enter fullscreen mode Exit fullscreen mode

4. Update the Dependency File 

google-genai==2.10.0
Enter fullscreen mode Exit fullscreen mode

5. Verify the Installed State Again 

pip show google-genai
Enter fullscreen mode Exit fullscreen mode

6. Run Automated Tests 

pytest test_prompts.py -v
Enter fullscreen mode Exit fullscreen mode

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

After completing the work, the following states were established:

  • The pip installation log revealed the dependency mismatch
  • The local environment was restored to google-genai 2.10.0
  • requirements.txt was updated to the same version
  • The Gemini API feature worked during manual testing
  • All three prompt-related pytest cases passed
  • The local environment and dependency configuration were synchronized

This provided a safer foundation for the next step:

Introducing Flask-Migrate and managing database schema history.

Summary

The main lessons from this work were:

  • Installation logs can reveal unintended package changes
  • A successful pip command does not mean the environment changed exactly as intended
  • Local packages and requirements.txt can drift apart
  • A clean CI or production environment follows the declared dependency configuration
  • Restoring a package locally is not enough; the configuration file must also be updated
  • Manual API verification and unit tests protect different parts of the application
  • Exact version pinning improves reproducibility but requires maintenance
  • Environment synchronization should be confirmed before introducing another major dependency

I originally intended only to prepare for Flask-Migrate.

Instead, I discovered and corrected a hidden dependency mismatch.

This was an unexpected detour, but it prevented the next stage of development from being built on an inconsistent environment.

This is Part 1 of a three-part series.

The next article will cover the introduction of Flask-Migrate and database migration management.

sales_data_app Maintenance Series

Pre-Production Inspection Trilogy

Post-Deployment Maintenance Series

🍞 sales_data_app on GitHub

Top comments (0)