6.1.1: problem with Version in src/pytest.egg-info/PKG-INFO anfter install

[kloczek]

I just found that my rpm package with pytest has some issiu. It reports wrong version because in installed pytest-*.egg-info/PKG-INFO is reported wrong version.

Dist src/pytest.egg-info/PKG-INFO is OK:

[tkloczko@barrel pytest-6.1.1]$ grep Version src/pytest.egg-info/PKG-INFO
Metadata-Version: 2.1
Version: 6.1.1

After /usr/bin/python3 setup.py build '--executable=/usr/bin/python3 -s' still everything is the same version in that file however

+ /usr/bin/python3 setup.py install -O1 --skip-build --root /home/tkloczko/rpmbuild/BUILDROOT/python-pytest-6.1.1-2.fc34.x86_64
writing src/pytest.egg-info/PKG-INFO <<#### HERE

and than after setup.py install suddenly:

[tkloczko@barrel pytest-6.1.1]$ grep Version src/pytest.egg-info/PKG-INFO
Metadata-Version: 2.1
Version: 0.0.0

That version is used by rpm dependencies generator which is causing that rpm package has in provides

python3.8dist(pytest) = 0
python3dist(pytest) = 0

By this my rpm package is broken because for example my other package with python pytest-forked require pytest >= 3.1.

Lookinng on dist tar ball 6.1.1 setup.cfg and setup.py I dont see anywhere defined version

[tkloczko@barrel pytest-6.1.1]$ grep -i version setup.cfg setup.py
setup.cfg:      importlib-metadata>=0.12;python_version<"3.8"
setup.cfg:      pathlib2>=2.2.0;python_version<"3.6"
setup.cfg:      src/_pytest/_version.py

so probably by this (re)generated version in PKG-INFO is 0.0.0

[kloczek]

Just found that patch:

--- a/setup.cfg~        2020-10-13 03:31:51.000000000 +0100
+++ b/setup.cfg 2020-10-13 03:32:02.825504089 +0100
@@ -1,5 +1,6 @@
 [metadata]
 name = pytest
+version = 6.1.1
 description = pytest: simple powerful testing with Python
 long_description = file: README.rst
 long_description_content_type = text/x-rst

fixes that issue.

[asottile]

that value being 0.0.0 implies you're not building in a supported way (via the sdist or via setuptools-scm) -- probably your setuptools version is too old?

[RonnyPfannschmidt]

pytest has a build time requirement of setuptools_scm

perhaps we should enforce it by placing a import in the setup.py that will cause failure on misaligned setups

[kloczek]

Yes, but that requirement works only with git tree and does not work with dist tar ball.
setup.py` should contain version this or another way.
Try to think that most of the build platforms used by different distributions are intentionally cut off from public network.

[The-Compiler]

FWIW I'd like to discuss dropping setuptools_scm - no personal offense intended, but I still think it's causing far more problems than it solves... I'd much rather just have a version number in setup.cfg - we have automated releases, so it really doesn't hurt to update a version number before creating a git tag, no?

[kloczek]

Just to give you guys kind of context ..
I'm building packages on really massive scale and I found that what really help me to keep whole packages populations in really healthy state is have executed on each package build process included test suites .. because in many occasions I found that fails in those suites are symptoms of some bugs (sometime not exactly in just build single package).

What I wat to say to the maintainer is that I fully understand that you as single python module maintainer have your own needs however if you would be able developing your source tree test suite to allow me use it as well I can guarantee that sooner or later I would be able to deliver you as feedback some data which will allow you improve your work as well :)

[nicoddemus]

@The-Compiler

FWIW I'd like to discuss dropping setuptools_scm - no personal offense intended, but I still think it's causing far more problems than it solves... I'd much rather just have a version number in setup.cfg - we have automated releases, so it really doesn't hurt to update a version number before creating a git tag, no?

You probably mean to update the version as part of the release process, as part of the release PR?

I'm not against the idea per-se, but this probably better be done in a separate issue so we can better discuss its pros and cons.

[nicoddemus]

@kloczek

I'm building packages on really massive scale and I found that what really help me to keep whole packages populations in really healthy state is have executed on each package build process included test suites .. because in many occasions I found that fails in those suites are symptoms of some bugs (sometime not exactly in just build single package).

Sure, and we appreciate that! I particularly understand that as I maintain several @conda-forge packages too. 😁

However the cause of your issue was not yet clear (at least to me). Can you explain how you are building pytest, and which setuptools version you are using? Thanks!

[ssbarnea]

I really doubt setuptools-scm is to blame here as I am a very happy user of it. Previously I was using pbr.

I seen this issue before and, at least in my case, it was caused by usage setup.py. That is why currently I (re)use a little bit less pure setup.py file, one that also works with editable installs.

[bnavigator]

This also happens on the openSUSE package for 6.1.1. It did not happen for 6.0.1

• sdist tar.gz from PyPI
• python3-setuptools-44.1.1-183.6
• python3-setuptools_scm-4.1.2-54.2

/usr/bin/python3 setup.py build '--executable=/usr/bin/python3 -s'

/usr/bin/python3 setup.py install -O1 --skip-build --force --root /home/abuild/rpmbuild/BUILDROOT/python-pytest-6.1.1-0.x86_64 --prefix /usr

[bnavigator]

... and it can be fixed either by #7891 (comment) or not forgetting to install toml 🤦

[ssbarnea]

I recently faced a weird issue building another package where it ended up with version 0.0.0, only inside a container, local cross platform and CI worked fine.

It seems that I have missed to mention toml in addition to setuptools-scm in the whole trinity: setup.cfg setup.py and pyproject.toml -- i hope i would help.

[nicoddemus]

Closing this for now, but we are happy to reopen if more information comes up! 👍