#9 Show the version as 7.0.0
Merged 4 years ago by churchyard. Opened 4 years ago by churchyard.
rpms/ churchyard/pypy3 sed_version  into  master

file modified
+12 -1
@@ -2,7 +2,7 @@ 

  Name:           pypy3

  Version:        %{basever}.0

  %global pyversion 3.5

- Release:        1%{?dist}

+ Release:        2%{?dist}

  Summary:        Python 3 implementation with a Just-In-Time compiler

  

  # LGPL and another free license we'd need to ask spot about are present in some
@@ -321,6 +321,14 @@ 

  %prep

  %autosetup -n pypy%{pyversion}-v%{version}-src -p1 -S git

  

+ # While this is 7.0.0, it has 7.1.0-alpha0 listed inside

+ # We sed it out to avoid user confusion

+ sed -i 's/7\.1\.0/7.0.0/' pypy/doc/conf.py

+ sed -i 's/7\.1\.0-alpha0/7.0.0/g' pypy/module/cpyext/include/patchlevel.h pypy/doc/how-to-release.rst

+ sed -i 's/0x07010000/0x07000000/' pypy/module/cpyext/include/patchlevel.h

+ sed -i 's/7, 1, 0, "alpha"/7, 0, 0, "final"/' pypy/module/sys/version.py

+ 

+ 

  %if %{with rpmwheels}

  %apply_patch -m %(basename %{SOURCE189}) %{SOURCE189}

  rm lib-python/3/ensurepip/_bundled/*.whl
@@ -869,6 +877,9 @@ 

  

  

  %changelog

+ * Thu May 16 2019 Miro Hrončok <mhroncok@redhat.com> - 7.0.0-2

+ - Show the version as 7.0.0

+ 

  * Thu Feb 28 2019 Miro Hrončok <mhroncok@redhat.com> - 7.0.0-1

  - Update to 7.0.0 (#1673127)

  

While this is 7.0.0, it has 7.1.0-alpha0 listed inside,
we sed it out to avoid user confusion.

Untested.

To demonstrate the problem:

$ pypy3 --version
Python 3.5.3 (d1e3583c9d87, Mar 04 2019, 22:37:30)
[PyPy 7.1.0-alpha0 with GCC 9.0.1 20190227 (Red Hat 9.0.1-0.8)]
$ rpm -q pypy3
pypy3-7.0.0-1.fc30.x86_64

pypy2 doesn't have this problem:

$ pypy2 --version
Python 2.7.13 (c0f118b7fc00, Mar 05 2019, 23:12:09)
[PyPy 7.0.0 with GCC 9.0.1 20190227 (Red Hat 9.0.1-0.8)]

It does not work.

[root@2c698a84873f src]# dnf list installed | grep pypy3
pypy3.x86_64                       7.0.0-2.fc31                    @@commandline
pypy3-devel.x86_64                 7.0.0-2.fc31                    @@commandline
pypy3-libs.x86_64                  7.0.0-2.fc31                    @@commandline

[root@2c698a84873f src]# pypy3 --version
Python 3.5.3 (701f9044d22e, May 16 2019, 23:00:41)
[PyPy 7.1.0-alpha0 with GCC 9.1.1 20190503 (Red Hat 9.1.1-1)]
$ grep -iIrn "7\.1\.0" ./
<nothing>
$ grep -iIrn "7\.0\.0" ./ | grep -v "127\.0\.0\.[012]"
./lib64/pypy3-7.0/lib-python/3/test/test_ipaddress.py:257:        assertBadOctet("257.0.0.0", 257)
./lib64/pypy3-7.0/include/patchlevel.h:35:#define PYPY_VERSION "7.0.0"

Metadata Update from @churchyard:
- Request assigned

4 years ago

Amended. Let's wait for the build.

rebased onto 3e4b720

4 years ago

Metadata Update from @churchyard:
- Request assignee reset

4 years ago

Looks good and works so you can merge it.

I just have one idea. What do you think about having the same change as a patch instead of sed commands? One reason is that it might be more readable and compact than the list of seds but the second reason (more important) is that when a sed command fails to change a version, a build continues but when a patch fails to apply then a build fails as well which can help us to spot a change in pypy source and then we can adapt the patch to a new version.

What do you think about it?

You certainly have a point, but I'll be updating to 7.1.0 soon anyway. If you have a strong preference, I can definitively go with a patch, but if not, it would b easier for me to just keep this as is.

You'll be the one who will do the update to 7.1.0 or at least review of update patch so I am ok with the change as is.

Pull-Request has been merged by churchyard

4 years ago