search

pytest-dev / pytest

The pytest framework makes it easy to write small tests, yet scales to support complex functional testing
https://pytest.org
MIT License
12.09k stars 2.68k forks source link

[packaging] Allow versioning arbitrary Git commits #11680

Open webknjaz opened 11 months ago

webknjaz commented 11 months ago

I noticed that the project doesn't implement the feature of setuptools-scm to deduce versions out of Git archives. It used to be a third party plugin and now its a part of the library.

To enable this, it's necessary to add .git_archival.txt and make a change to .gitattributes per the project docs.

RonnyPfannschmidt commented 11 months ago

When support for arbitrary commits is enabled the content of tagged archives changes based on the referring branches due to how git works

Pierre-Sassoulas commented 11 months ago

It also add a dependency to setuptools, git, and the full repository history to be able to know the version of the code. It become impossible to just recover the latest commit with a shallow copy to work on it locally, the version is broken otherwise. A tarball of the code would also have no version. If you have access to git and the full repository history, then being able to tell what is the current head is git rev-parse HEAD and you don't need setuptools to do that.

webknjaz commented 11 months ago

@Pierre-Sassoulas setuptools-scm is already integrated and already depends on Git to deduce the version when building from a Git checkout. What I'm proposing actually solves one of your concerns — building from a Git archive, which is a tarball you can get via direct GitHub URLs to commits like https://github.com/pytest-dev/pytest/archive/d1675646f2d5f218cbaae5b88f3b5dee5a5061ca.tar.gz (this currently only works for tag URLs). Note that this only concerns building an sdist or a wheel from a Git archive tarball. The presence of Git itself or the Git tree is not needed in this case.

When support for arbitrary commits is enabled the content of tagged archives changes based on the referring branches due to how git works

@RonnyPfannschmidt is that a conscious decision by the team or a historic state of things? Any desire to change this?

RonnyPfannschmidt commented 11 months ago

It's a issue with git itself and how GitHub produces archives

webknjaz commented 11 months ago

I know. I'm asking about the decision whether to enable the plugin.

RonnyPfannschmidt commented 11 months ago

I never enabled it due to the mentioned issues with the changes of content hashes for the archives

webknjaz commented 1 month ago

@RonnyPfannschmidt I think that with the recent setuptools-scm instructions it should be possible to make the git archives immutable, right?