What’s the master branch‘s actual current package version?

[jenstroeger]

Looking at the package metadata on the master branch at today’s commit 6282143 I see

moto/setup.cfg

Lines 1 to 3 in 6282143

	[metadata]
	name = moto
	version = 4.1.0.dev

and also

moto/moto/__init__.py

Lines 3 to 4 in 6282143

	__title__ = "moto"
	__version__ = "5.0.12.dev"

Release v5.0.11 was released from commit 4867e69 which shows

moto/setup.cfg

Lines 1 to 3 in 4867e69

	[metadata]
	name = moto
	version = 4.1.0.dev

and

moto/moto/__init__.py

Lines 3 to 4 in 4867e69

	__title__ = "moto"
	__version__ = "5.0.11.dev"

Can I assume that the current metadata in setup.cfg is incorrect? This matters when I want to install a branch locally (and in editable mode) because pip thinks the package is v4 but it actually seems to be v5:

> python -m pip install --pre --upgrade --upgrade-strategy eager --editable . --editable ../moto/
...

ERROR: Cannot install moto 4.1.0.dev0 (from /path/to/dev/moto) and my-app-package==0.43.3a0 because these package versions have conflicting dependencies.

The conflict is caused by:
    The user requested moto 4.1.0.dev0 (from /path/to/dev/moto)
    my-app-package 0.43.3a0 depends on moto<5.1.0 and >=5.0.0; extra == "test"

To fix this you could try to:
1. loosen the range of package versions you've specified
2. remove package versions to allow pip to attempt to solve the dependency conflict

ERROR: ResolutionImpossible: for help visit https://pip.pypa.io/en/latest/topics/dependency-resolution/#dealing-with-dependency-conflicts

Also, it seems that the artifacts on PyPI and attached to the release (e.g. moto-5.0.11.tar.gz) are built from a different commit or a modified version of the master branch than the actual release commit 4867e69, because the artifact attached to the release contains

__title__ = "moto"
__version__ = "5.0.11"

which differs from the release commit.

[bblommers]

Can I assume that the current metadata in setup.cfg is incorrect?

Yes, that assumption is correct. The mismatch of versions was a combination of not committing the right files after updating the version number, and releasing a dirty version of the repository (with uncomitted changes).

PR #7929 fixed it - release 5.0.12 (just out) now contains the proper versions all around, and points to the correct commit.

Thanks for pointing this out @jenstroeger!