Skip to content

Fix "make rpm" #172

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ldoktor wants to merge 2 commits into
base: main
Choose a base branch
from
+10 −5
Open

Fix "make rpm" #172

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
4f9f6ab
Makefile: Fix "make rpm" and "make release-rpm"
ldoktor Jul 21, 2026
0d2aca8
pyproject: Keep using dynamic for pypi with fallback for rpm build
ldoktor Jul 21, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 5 additions & 4 deletions Makefile
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,7 @@
PYTHON=$(shell which python 2>/dev/null || which python3 2>/dev/null)
PROJECT=aexpect
VERSION=$(shell $(PYTHON) -m setuptools_scm)
VERSION=$(shell $(PYTHON) -m setuptools_scm 2>/dev/null || grep '^Version:' python-$(PROJECT).spec | awk '{print $$2}')
SPEC_VERSION=$(shell grep '^Version:' python-$(PROJECT).spec | awk '{print $$2}')

@pevogam pevogam Jul 24, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line seems repetitive of the one above, how about simply getting SPEC_VERSION first and then retrieving the backup version directly from this variable being already set?

@ldoktor ldoktor Jul 29, 2026

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure

COMMIT=$(shell git log --pretty=format:'%H' -n 1)
SHORT_COMMIT=$(shell git log --pretty=format:'%h' -n 1)
COMMIT_DATE=$(shell git log --pretty='format:%cd' --date='format:%Y%m%d' -n 1)
Expand All @@ -25,7 +26,7 @@ source: clean

source-release: clean
mkdir -p SOURCES
git archive --prefix="$(PROJECT)-$(VERSION)/" -o "SOURCES/$(PROJECT)-$(VERSION).tar.gz" $(VERSION)
git archive --prefix="$(PROJECT)-$(SPEC_VERSION)/" -o "SOURCES/$(PROJECT)-$(SPEC_VERSION).tar.gz" $(SPEC_VERSION)

@pevogam pevogam Jul 24, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I assume this and the below diff blocks need SPEC_VERSION explicitly? What would happen if the SPEC_VERSION differs from the VERSION here? Would this still be reasonable?

@ldoktor ldoktor Jul 29, 2026

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The previous (hardcoded) version used a fixed version to avoid problems passing it between mock and the repo. To keep this behaviour I added the SPEC_VERSION which is used for rpm targets while keeping it dynamic for the other targets. So different version should result in the RPM force-setting to the SPEC one.

Ideally I'd like to remove the SPEC_VERSION completely, but you claimed it didn't work on your build system.

@pevogam pevogam Jul 31, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The previous (hardcoded) version used a fixed version to avoid problems passing it between mock and the repo. To keep this behaviour I added the SPEC_VERSION which is used for rpm targets while keeping it dynamic for the other targets. So different version should result in the RPM force-setting to the SPEC one.

Meaning that we still have to maintain at least one hard-coded version or somewhat worse yet we may want to ignore it and only rely on the dynamical version in all other cases, ending up with diverging versions. Of course one may argue that manual version maintenance is now restricted to just people caring about the RPM deployment but at the same time it does sound like it will be much more tempting for everyone else to just ignore updating it and for the project to end up with different python versions.

Ideally I'd like to remove the SPEC_VERSION completely, but you claimed it didn't work on your build system.

If you want you could suggest a more daring dynamic version and I could still try it. I am performing my integration testing in a fairly isolated Fedora 42+ LXC container without adding much complexity to such testing environment beyond the goal of running avocado plugins.


install:
rm -r dist 2>/dev/null || true
Expand Down Expand Up @@ -74,15 +75,15 @@ srpm: source

rpm: srpm
mkdir -p BUILD/RPM
mock -r $(MOCK_CONFIG) --resultdir BUILD/RPM -D "rel_build 0" -D "commit $(COMMIT)" -D "commit_date $(COMMIT_DATE)" --rebuild BUILD/SRPM/python-$(PROJECT)-$(VERSION)-*.src.rpm
mock -r $(MOCK_CONFIG) --resultdir BUILD/RPM -D "rel_build 0" -D "commit $(COMMIT)" -D "commit_date $(COMMIT_DATE)" --rebuild BUILD/SRPM/python-$(PROJECT)-$(SPEC_VERSION)-*.src.rpm

srpm-release: source-release
mkdir -p BUILD/SRPM
mock -r $(MOCK_CONFIG) --resultdir BUILD/SRPM -D "rel_build 1" --buildsrpm --spec python-$(PROJECT).spec --sources SOURCES

rpm-release: srpm-release
mkdir -p BUILD/RPM
mock -r $(MOCK_CONFIG) --resultdir BUILD/RPM -D "rel_build 1" --rebuild BUILD/SRPM/python-$(PROJECT)-$(VERSION)-*.src.rpm
mock -r $(MOCK_CONFIG) --resultdir BUILD/RPM -D "rel_build 1" --rebuild BUILD/SRPM/python-$(PROJECT)-$(SPEC_VERSION)-*.src.rpm

clean:
$(MAKE) -f $(CURDIR)/debian/rules clean || true
Expand Down
3 changes: 2 additions & 1 deletion pyproject.toml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ build-backend = "setuptools.build_meta"
name = "aexpect"
description = "Python library used to control interactive programs"
readme = "README.rst"
version = "1.8.0"
dynamic = ["version"]
license = {text = "GPL-2.0-or-later"}
authors = [{name = "Aexpect developers", email = "avocado-devel@redhat.com"}]
maintainers = [{name = "Aexpect developers", email = "avocado-devel@redhat.com"}]
Expand Down Expand Up @@ -44,6 +44,7 @@ include = ["aexpect*"]
[tool.setuptools_scm]
version_scheme = "post-release"
local_scheme = "node-and-date"
fallback_version = "1.8.0"

@pevogam pevogam Jul 24, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So in some sense we still end up with non-dynamic version, no? Because either we have to update this each time as we would have updated version or we don't update it but get strange cases where higher version might display as lower version which could cause some havoc in deployment pipelines.


[tool.black]
line-length = 79
Expand Down
3 changes: 3 additions & 0 deletions python-aexpect.spec
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -37,7 +37,9 @@ Source0: %{url}/archive/%{commit}/%{gittar}

BuildArch: noarch
BuildRequires: python3-devel
BuildRequires: python3-pip
BuildRequires: python3-setuptools
BuildRequires: python3-setuptools_scm

%description
Aexpect is a python library used to control interactive applications, very
Expand All @@ -60,6 +62,7 @@ sftp, telnet, among others.
%endif

%build
export SETUPTOOLS_SCM_PRETEND_VERSION=%{version}

@pevogam pevogam Jul 31, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For some comparison, here is the diff with my draft that failed to achieve a build so far:

---
 aexpect/__init__.py | 2 ++
 pyproject.toml      | 1 +
 python-aexpect.spec | 7 +++++++
 3 files changed, 10 insertions(+)

diff --git a/aexpect/__init__.py b/aexpect/__init__.py
index 3e32262..6d714d1 100644
--- a/aexpect/__init__.py
+++ b/aexpect/__init__.py
@@ -14,6 +14,8 @@ Aexpect module, see help('aexpect.client') to get info about the main
 entry-points.
 """

+# _version is generated by tool.setuptools_scm
+from ._version import version as __version__
 from . import remote, rss_client
 from .client import (
     Expect,
diff --git a/pyproject.toml b/pyproject.toml
index 3975c3d..dfb3782 100644
--- a/pyproject.toml
+++ b/pyproject.toml
@@ -44,6 +44,7 @@ include = ["aexpect*"]
 [tool.setuptools_scm]
 version_scheme = "post-release"
 local_scheme = "node-and-date"
+write_to = "aexpect/_version.py"

 [tool.black]
 line-length = 79
diff --git a/python-aexpect.spec b/python-aexpect.spec
index 955ef09..0066d36 100644
--- a/python-aexpect.spec
+++ b/python-aexpect.spec
@@ -36,8 +36,10 @@ Source0: %{url}/archive/%{commit}/%{gittar}
 %endif

 BuildArch: noarch
+BuildRequires: pyproject-rpm-macros
 BuildRequires: python3-devel
 BuildRequires: python3-setuptools
+BuildRequires: python3-setuptools-scm

 %description
 Aexpect is a python library used to control interactive applications, very
@@ -59,7 +61,12 @@ sftp, telnet, among others.
 %autosetup -n aexpect-%{commit} -p 1
 %endif

+%generate_buildrequires
+export SETUPTOOLS_SCM_PRETEND_VERSION=%{version}
+%pyproject_buildrequires
+
 %build
+export SETUPTOOLS_SCM_PRETEND_VERSION=%{version}
 %pyproject_wheel

 %install

%pyproject_wheel

%install
Expand Down
Loading