Independent genai versioned packages are tested with monorepo dependencies

[aabmass]

We have independent releases for some genai packages, but the tox setup in this repo still installs monorepo deps for testing. For example:

• opentelemetry-instrumentation-google-genai depends on
  • opentelemetry-instrumentation
  • opentelemetry-util-genai

but the requirements files that tox uses installs those from the monorepo (for both oldest and latest)

opentelemetry-python-contrib/instrumentation-genai/opentelemetry-instrumentation-google-genai/tests/requirements.oldest.txt

Lines 33 to 37 in a025a20

	# Install locally from the folder. This path is relative to the
	# root directory, given invocation from "tox" at root level.
	-e instrumentation-genai/opentelemetry-instrumentation-google-genai
	# TODO: remove local install after release (https://github.com/open-telemetry/opentelemetry-python-contrib/issues/4221)
	-e util/opentelemetry-util-genai[upload]

This is problematic because those packages are not released at the same time, so the monorepo version is not available after publishing. The tests don't reflect the reality of what users see after releasing. However it's convenient for development, for example making an update to opentelemetry-util-genai and opentelemetry-instrumentation-google-genai at the same time. It also makes the release painful (see #4230). Some possible options to fix it

1. Strictly only test against published versions (for both oldest and latest). Never use any monorepo deps for independent versioned packages. The downside is that it's hard to develop new features in opentelemetry-util-genai without releasing it after every change.
2. Do away with independent versioned pacakges. Go back to strict lockstep releases of contrib.
3. Live with the testing not being accurate.
4. Test against monorepo deps on main, but release branches (created by package-prepare-release workflow) only test against published versions. Updating the package-prepare-release workflow to do this might be a little painful, but maybe solves all of the above?

[xrmx]

Testing against git in CI has the positive effect on catching util-genai breakages for genai instrumentations early. Not sure how often that has happened or if genai instrumentations authors care about that. OTOH you really want to test instrumentations against the util-genai version you have in pyproject.toml. So maybe we should test each instrumentations against baseline util-genai, latest util-genai and main?

[aabmass]

So maybe we should test each instrumentations against baseline util-genai, latest util-genai and main?

The problem here is as soon you start building against a new feature in util-genai, the baseline and latest will start failing. We could just allow the tests to fail