test: fix version_test failing on old venv

[dangotbanned]

What type of PR is this? (check all applicable)

• 💾 Refactor
• ✨ Feature
• 🐛 Bug Fix
• 🔧 Optimization
• 📝 Documentation
• ✅ Test
• 🐳 Other

Related issues

• chore: Add CompliantNamespace.is_native #3130 (review)
• feat: introduce (experimental) plugin system #2978 (comment)
• feat: introduce (experimental) plugin system #2978 (comment)
• feat: introduce (experimental) plugin system #2978 (comment)

Checklist

• Code follows style guide (ruff)
• Tests added
• Documented the changes

If you have comments or can explain your changes, please do so below

(#3130 (comment))

The failure in (#3130 (review)) happens when your venv was installed against a previous version of narwhals.
In this case 2.4.0, which just means you need to reinstall to get (v2.5.0 (release)) 🙂

I also get bitten by that test regularly and was thinking about rewriting it yesterday 😭
We should really be testing against the version that is locally installed - which can be older than pyproject.toml

[FBruzzesi]

While I understand that locally this can be problematic (it happened to me multiple times), I am not sure that working around the test itself is the best solution here.

• In CI this should never happen, unless we are actually doing something wrong, and if that's the case, we could end up not noticing it.
• I would suggest to add a message in the current assert that explicitly suggestion why this happens and what to do, something along the lines of:

- assert nw.__version__ == pyproject_version
+ msg = "metadata is out of sync, either ignore this failure locally or re-install narwhals: `uv pip install -e .`"
+ assert nw.__version__ == pyproject_version, msg

[dangotbanned]

Thanks for the review @FBruzzesi

In CI this should never happen, unless we are actually doing something wrong, and if that's the case, we could end up not noticing it.

You make a good point! 😄

Would (2f22890) and (0500e3c) help alleviate this concern?
(provided I've RTFM correctly 😂)

[dangotbanned]

#3134 (comment)

I am not sure that working around the test itself is the best solution here

I get that using pyproject.toml provides a proxy value with a different static source (+1).
But as we don't use a lockfile, I don't think it quite fits this definition of assertion

... that always should evaluate to true at that point in code execution

We've both sadly experienced this not being an always - because of how it interacts with -e 😔

So the question for me was:
Is there anything else we can confidently assert, where a failure still indicates a regression?

Given that this is a very thin wrapper around importlib.metadata.version our options are limited:

narwhals/narwhals/__init__.py

Lines 176 to 183 in 8bee263

	def __getattr__(name: _t.Literal["__version__"]) -> str: # type: ignore[misc]
	if name == "__version__":
	global __version__ # noqa: PLW0603
	from importlib import metadata
	__version__ = metadata.version(__name__)
	return __version__

But we can use that to our advantage! To me, that implies the likely points for breakage are:

1. A future refactor changes how we wrap version
2. We revert back to not using version

In either case - we'll know that something is wrong because nw.__version__ no longer returns a string that is equal to importlib.metadata.version("narwhals").

[FBruzzesi]

Thanks @dangotbanned 🙏🏼 nice trick for GHA 😉