`versioneer`/`setuptools_scm` are unable to infer the correct version

[brendan-ward]

We are extending the manylinux2014_x86_64 Docker image to build binary dependencies using VCPKG. This worked nicely until the latest changes in quay.io/pypa/manylinux2014_x86_64:2022-04-18-1d09d31.

Previously we were getting proper wheel names: pyogrio-0.3.0+47.g9dd1b49-cp38-cp38-linux_x86_64.whl

On latest version we now get: pyogrio-0+unknown-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl

We are using versioneer for managing versions, but as that was working previously, I'm not sure that is the issue here. Given that the names now include "manylinux*" it suggests that perhaps there is an issue in one of the build scripts in this latest version?

Downgrading to the quay.io/pypa/manylinux2014_x86_64:2022-04-03-da6ecb3 image fixed our issue.

xref: geopandas/pyogrio#77

[jorisvandenbossche]

Given that the names now include "manylinux*" it suggests that perhaps there is an issue in one of the build scripts in this latest version?

Small correction here: also on the latest docker image, we get a name like pyogrio-0+unknown-cp38-cp38-linux_x86_64.whl initially. The name including "manylinux" is the one after repairing with auditwheel.

It might be an issue with the git update?

[jorisvandenbossche]

It might be an issue with the git update?

From the recent release notes:

With the fixes for CVE-2022-24765 that are common with versions of
Git 2.30.4, 2.31.3, 2.32.2, 2.33.3, 2.34.3, and 2.35.3, Git has
been taught not to recognise repositories owned by other users, in
order to avoid getting affected by their config files and hooks.
You can list the path to the safe/trusted repositories that may be
owned by others on a multi-valued configuration variable
safe.directory to override this behaviour, or use '*' to declare
that you trust anything.

[brendan-ward]

Setting

git config --global --add safe.directory "*"

Within our Dockerfile appears to have resolved this issue. This may be more permissive than appropriate for all use cases, but for running on Github Actions it seemed fine. Is it appropriate to add something similar to the base Dockerfiles here?

Looks like this is not an isolated case of git upgrades breaking things in recent days...

[mayeut]

Thanks for the report & the analysis.
I'm a bit hesitant to apply this config by default for now as it's dealing with some security issue & this just revert the security fix.

[jorisvandenbossche]

pypa/cibuildwheel#1095 indicates another way this can be fixed (although it might be specific to cibuildwheel, didn't look in detail)

[henryiii]

Users also can fix by being explicit, like in pypa/setuptools-scm#708. Or by ensuring the file ownership has a consistent user all the way up (tar needs the flag in the cibuildwheel link, for example).

[tylerjereddy]

I'm a bit less clear on how to solve this as a consumer of multibuild (until we migrate SciPy to cibiuldwheel)--i.e., MacPython/scipy-wheels#167.

I tried messing around with a few different things, but each seemed to have different problems--i.e., the custom git commands would complain about permissions issues, and attempts to pin to older Docker containers seemed a bit tricky since much of the work is done upstream by multibuild.