Installation issue with date tag appended to version string

Python Help
1

I have the following repository structure

\libs
  \lib1
    \src
    - pyproject.toml
    - setup.cfg
  \lib2
    \src
    - pyproject.toml
    - setup.cfg

setup.cfg for lib2 contains a reference to lib1

[options]
python_requires = >=3.10
include_package_data = True
install_requires =
  retrying==1.3.4
  lib1

toml file contents (this is for lib1 but the one for lib2 is identical except the write_to path)

[build-system]
requires = ["setuptools>=42", "wheel", "setuptools_scm>=6.2"]
build-backend = "setuptools.build_meta"

[tool.setuptools_scm]
write_to = "libs/lib1/src/lib1/_version.py"
root = "../.."

Below is a snippet for my gitlab pipeline. The version string is “0.8.1.dev10+g8295033” and lib1 gets installed with the correct version string appended. However for lib2 a date tag is appended to the version string “0.8.1.dev10+g8295033.d20231020”. I can’t figure out why and have no idea how to debug this behavior. If I make lib2 not require/depend on lib1 the “.d20231020” is not appended. Does anyone have an idea about why the date tag gets appended or just ideas of things to try?
I did try to write

[egg-info]
tag-date = 0

in setup.cfg but it didn’t do anything

export VERSION=(python -m setuptools_scm)
/usr/local/lib/python3.10/site-packages/setuptools_scm/git.py:163: UserWarning: “/builds/long_path/python-packages/repository_name” is shallow and may cause errors
warnings.warn(f’“{wd.path}” is shallow and may cause errors’)
$ echo $VERSION
0.8.1.dev10+g8295033

cd’ing into libs/lib1
pip install .[test] --index-url “~ · GitLab”
Created wheel for lib1: filename=lib1-0.8.1.dev10+g8295033-py3-none-any.whl size=63037 sha256=b883d243c03f7057a547ff0e2c3b33b0083240881aeecd838cfe68af8bb53692

cd’ing into libs/lib2
running the install command again
Created wheel for lib2: filename=lib2-0.8.1.dev10+g8295033.d20231020-py3-none-any.whl size=19856 sha256=9a5449bc921c10a42390af0429e0f7170cade2679039cd8b9f1db9d1d37725c9

2

Hey Jawal so from setuptools_scm docs…from what I understand is that the setuptools_scm will consider both or rather each package state as separate. If lib2 is dependent on lib1 the the last changes you made on lib2 then the last git changes to that library or package will be its last state… so its like the date tag is being appended to reflect the last state

Builtin mechanisms for obtaining version numbers:
  1.the scm itself (git/hg)

  2 .hg_archival files (mercurial archives)

3.PKG-INFO

Note git archives are not supported due to git shortcomings

check with https://pypi.org/project/setuptools-scm/1.9.0/

Also from github_doc I got the below

setuptools-scm extracts Python package versions from git or hg metadata instead of declaring them as the version argument or in an SCM managed file.

3

Hi Kyle, thank you very much for your help. Based on your feedback I have an idea of what is going on that can explain the behavior. Unfortunately, I don’t know how to work around it.

From the link to the setuptools_scm documentation that you provided I can read this

no distance and not clean:

{tag}+dYYYMMMDD

First I couldn’t make sense of this because locally both lib dirs have uncommitted changes (files not tracked by git).

But then the behavior is seen in a gitlab pipeline where the repository is checkout out on some virtual machine or something. So my hypothesis is that when lib2 is dependent on lib1 then the installation of lib1 writes something to the lib2 dir or a subdir making lib2 not clean and setuptools_scm append the date. And when lib2 is not dependent on lib1 then nothing is written to the lib2 dir.

At least for some reason I can’t really understand that when installing lib2 setuptools_scm finds the repos or lib2 dir ‘not clean’.

But I’m not sure if this is really what is going on.

4

Sorry for taking your time. I found the issue and it was my own fault :frowning:
It was due to the fact that when building lib2 a very small script inserted the version into the setup.cfg in lib2, like this under install_requires as the version number is not know ahead of building/installation

lib1={{version}}

so that made the repository dirty when making lib2 dependent on lib1.
Thnx

5

Hey its all good man no need to be sorry your win is my win plus I get to learn… cheeers