#127 Set %__python3 value according to %python3_pkgversion
Merged 2 years ago by churchyard. Opened 2 years ago by churchyard.
rpms/ churchyard/python-rpm-macros pkg_exec  into  rawhide

file modified
+19 -19
@@ -1,22 +1,3 @@ 

- # Define the Python interpreter paths in the SRPM macros so that

- # - they can be used in Build/Requires

- # - they can be used in non-Python packages where requiring pythonX-devel would

- #   be an overkill

- 

- # use the underscored macros to redefine the behavior of %%python3_version etc.

- %__python2 /usr/bin/python2

- %__python3 /usr/bin/python3

- 

- # use the non-underscored macros to refer to Python in spec, etc.

- %python2 %__python2

- %python3 %__python3

- 

- # See https://fedoraproject.org/wiki/Changes/PythonMacroError

- %__python %{error:attempt to use unversioned python, define %%__python to %{__python2} or %{__python3} explicitly}

- 

- # Users can use %%python only if they redefined %%__python (e.g. to %%__python3)

- %python %__python

- 

  # There are multiple Python 3 versions packaged, but only one can be the "main" version

  # That means that it owns the "python3" namespace:

  #     - python3 package name
@@ -49,6 +30,25 @@ 

  # Alternatively, it can be overridden in spec (e.g. to "3.8") when building for alternate Python stacks.

  %python3_pkgversion 3

  

+ # Define the Python interpreter paths in the SRPM macros so that

+ # - they can be used in Build/Requires

+ # - they can be used in non-Python packages where requiring pythonX-devel would

+ #   be an overkill

+ 

+ # use the underscored macros to redefine the behavior of %%python3_version etc.

+ %__python2 /usr/bin/python2

+ %__python3 /usr/bin/python%{python3_pkgversion}

+ 

+ # use the non-underscored macros to refer to Python in spec, etc.

+ %python2 %__python2

+ %python3 %__python3

+ 

+ # See https://fedoraproject.org/wiki/Changes/PythonMacroError

+ %__python %{error:attempt to use unversioned python, define %%__python to %{__python2} or %{__python3} explicitly}

+ 

+ # Users can use %%python only if they redefined %%__python (e.g. to %%__python3)

+ %python %__python

+ 

  # Define where Python wheels will be stored and the prefix of -wheel packages

  # - In Fedora we want wheel subpackages named e.g. `python-pip-wheel` that

  #   install packages into `/usr/share/python-wheels`. Both names are not

file modified
+5 -1
@@ -49,7 +49,7 @@ 

  end

  }

  Version:        %{__default_python3_version}

- Release:        13%{?dist}

+ Release:        14%{?dist}

  

  BuildArch:      noarch

  
@@ -145,6 +145,10 @@ 

  

  

  %changelog

+ * Wed Dec 08 2021 Miro Hrončok <mhroncok@redhat.com> - 3.10-14

+ - Set %%__python3 value according to %%python3_pkgversion

+   I.e. when %%python3_pkgversion is 3.12, %%__python3 is /usr/bin/python3.12

+ 

  * Mon Nov 01 2021 Karolina Surma <ksurma@redhat.com> - 3.10-13

  - Fix multiline arguments processing for %%py_check_import

  Resolves: rhbz#2018809

file modified
+17 -2
@@ -83,6 +83,17 @@ 

                                     shell=True).rstrip()

  

  

+ @pytest.mark.parametrize('macro', ['%__python3', '%python3'])

+ def test_python3(macro):

+     assert rpm_eval(macro) == ['/usr/bin/python3']

+ 

+ 

+ @pytest.mark.parametrize('macro', ['%__python3', '%python3'])

+ @pytest.mark.parametrize('pkgversion', ['3', '3.9', '3.12'])

+ def test_python3_with_pkgversion(macro, pkgversion):

+     assert rpm_eval(macro, python3_pkgversion=pkgversion) == [f'/usr/bin/python{pkgversion}']

+ 

+ 

  @pytest.mark.parametrize('argument, result', [

      ('a', 'a'),

      ('a-a', 'a-a'),
@@ -647,7 +658,9 @@ 

  

  def test_python3_sitelib_value_alternate_python(alt_x_y):

      macro = '%python3_sitelib'

-     assert rpm_eval(macro, __python3=f'/usr/bin/python{alt_x_y}') == [f'/usr/lib/python{alt_x_y}/site-packages']

+     assert (rpm_eval(macro, __python3=f'/usr/bin/python{alt_x_y}') ==

+             rpm_eval(macro, python3_pkgversion=alt_x_y) ==

+             [f'/usr/lib/python{alt_x_y}/site-packages'])

  

  

  def test_python_sitearch_value_python3(lib):
@@ -667,7 +680,9 @@ 

  

  def test_python3_sitearch_value_alternate_python(lib, alt_x_y):

      macro = '%python3_sitearch'

-     assert rpm_eval(macro, __python3=f'/usr/bin/python{alt_x_y}') == [f'/usr/{lib}/python{alt_x_y}/site-packages']

+     assert (rpm_eval(macro, __python3=f'/usr/bin/python{alt_x_y}') ==

+             rpm_eval(macro, python3_pkgversion=alt_x_y) ==

+             [f'/usr/{lib}/python{alt_x_y}/site-packages'])

  

  

  @pytest.mark.parametrize(

I.e. when %python3_pkgversion is 3.12, %__python3 is /usr/bin/python3.12

We assume that when packagers pacakge for Python 3.X, they want to change both
%python3_pkgversion and %__python3 value.

Hence instead of copy-pasting this:

%global python3_pkgversion 3.X
%global __python3 /usr/bin/python3.X

They just need to do:

%global python3_pkgversion 3.X

Packagers who want to change the value of %__python3 without touching
%python3_pkgversion can still do it:

%global __python3 /usr/bin/pypy3

Related to https://bugzilla.redhat.com/1821489

Build succeeded.

Are we sure that using the python3_pkgversion macro above its own definition will be ok in all contexts?

I'd consider moving it even just for readability.

Besides that the code looks good, test coverage seems adequate. +1

rebased onto b55e615

2 years ago

Pretty sure, yes, but moved for readability. I've done it in the previous commit, so the diff is easier for review.

Build succeeded.

Packagers who wan tto change the value of %__python3 withotu

Minor typos in the commit message.

Pretty sure, yes, but moved for readability. I've done it in the previous commit, so the diff is easier for review.

Beautiful diff, just how I like it, thanks :)

Overall code looks good. How do we do testing?

Packagers who wan tto change the value of %__python3 withotu

Minor typos in the commit message.

Amedned.

2 new commits added

  • Set %__python3 value according to %python3_pkgversion
  • Move %python3_pkgversion definition earlier in the file
2 years ago

How do we do testing?

Well, I wonder how. I am 100 % that packages that do not redefine %__python3 or %python3_pkgversion should remain unaffected. I'Ve grepped trough all Fedora Rawhide specfiles and I found only this:

%{!?python3_pkgversion: %global python3_pkgversion 3}
%global python3_pkgversion 3
%if 0%{?rhel} == 7
%global python3_pkgversion 36
%endif
%{!?__python3: %global __python3 python3}
%if %{defined el8}
%global __python3 %{_libexecdir}/platform-python
%endif

All of which should not matter.

So the overall assumption here is that this change should have absolutely no impact. Hence a test might be to build a random selection of packages in Copr and rebuild all failures in another Copr. Would 1000 packages work for you?

Build succeeded.

Packagers who wan tto change the value of %__python3 withotu

Minor typos in the commit message.

Amedned.

Minor typo in the confirmation of the removal of typos.

So the overall assumption here is that this change should have absolutely no impact. Hence a test might be to build a random selection of packages in Copr and rebuild all failures in another Copr. Would 1000 packages work for you?

1000 is certainly plenty. And the assumption is that if it fails to build in the first copr (with the new macros), it should also fail in the second (clean) copr? And then compare the first copper with rawhide and see if something changed (random example python(abi) Provides?)?

Well, I wouldn't go that far as checking provides.

All failures either:

  • timed out (gcc, chromium)
  • were transient and succeeded when rebuilt
  • also fail in the control copr

With the exception of kernel and opencv -- they are still building in the control copr (and opencv also in the actual one).

I believe this is safe but if there is a particular check you want me to run, I can.

Random check:

$ rpmdiff -iT python3-uvicorn-0.15.0-1.fc36.noarch*
(empty)
$ rpmdiff -iT python-uvicorn-0.15.0-1.fc36.src*
(empty)
$ rpmdiff -iT python3-uvicorn+standard-0.15.0-1.fc36.noarch*
(empty)

All failures either:

  • timed out (gcc, chromium)
  • were transient and succeeded when rebuilt
  • also fail in the control copr

With the exception of kernel and opencv -- they are still building in the control copr (and opencv also in the actual one).

I believe this is safe but if there is a particular check you want me to run, I can.

Random check:

$ rpmdiff -iT python3-uvicorn-0.15.0-1.fc36.noarch* (empty) $ rpmdiff -iT python-uvicorn-0.15.0-1.fc36.src* (empty) $ rpmdiff -iT python3-uvicorn+standard-0.15.0-1.fc36.noarch* (empty)

I agree, this is sufficient testing, LGTM.

Pull-Request has been merged by churchyard

2 years ago