#501 Remove dependency on hawkey and python3-dnf
Opened 8 months ago by thebeanogamer. Modified 8 months ago
thebeanogamer/FedoraReview nohawkey  into  master

file modified
-2
@@ -32,7 +32,6 @@ 

  BuildRequires:  python3-straight-plugin

  BuildRequires:  python3-devel

  BuildRequires:  python3-rpm

- BuildRequires:  python3-dnf

  

  Requires:       fedora-packager

  Requires:       python3-beautifulsoup4
@@ -41,7 +40,6 @@ 

  Requires:       python3-urlgrabber

  Requires:       python3-straight-plugin

  Requires:       python3-rpm

- Requires:       python3-dnf

  # licensecheck used to be in rpmdevtools, moved to devscripts later

  # this is compatible with both situations without ifdefs

  Requires:       %{_bindir}/licensecheck

file modified
+46 -3
@@ -31,9 +31,7 @@ 

  import subprocess

  import sys

  

- from dnf.rpm import basearch

- from hawkey import detect_arch

- from packaging import version

+ from platform import machine as detect_arch

  

  from . import ansi

  from .review_error import ReviewError
@@ -43,6 +41,51 @@ 

  

  SESSION_LOG = os.path.join(XdgDirs.cachedir, "fedora-review.log")

  

+ # Begin bad things

+ # This is stolen from dnf.rpm so that we don't have to deal with importing that entire module

+ # It also means we don't have to get a working shim for dnf/libdnf/libcomps/hawkey on PyPi

+ 

+ 

+ def _invert(dct):

+     return {v: k for k in dct for v in dct[k]}

+ 

+ 

+ _BASEARCH_MAP = _invert({

+     'aarch64': ('aarch64',),

+     'alpha': ('alpha', 'alphaev4', 'alphaev45', 'alphaev5', 'alphaev56',

+               'alphaev6', 'alphaev67', 'alphaev68', 'alphaev7', 'alphapca56'),

+     'arm': ('armv5tejl', 'armv5tel', 'armv5tl', 'armv6l', 'armv7l', 'armv8l'),

+     'armhfp': ('armv6hl', 'armv7hl', 'armv7hnl', 'armv8hl'),

+     'i386': ('i386', 'athlon', 'geode', 'i386', 'i486', 'i586', 'i686'),

+     'ia64': ('ia64',),

+     'mips': ('mips',),

+     'mipsel': ('mipsel',),

+     'mips64': ('mips64',),

+     'mips64el': ('mips64el',),

+     'loongarch64': ('loongarch64',),

+     'noarch': ('noarch',),

+     'ppc': ('ppc',),

+     'ppc64': ('ppc64', 'ppc64iseries', 'ppc64p7', 'ppc64pseries'),

+     'ppc64le': ('ppc64le',),

+     'riscv32' : ('riscv32',),

+     'riscv64' : ('riscv64',),

+     'riscv128' : ('riscv128',),

+     's390': ('s390',),

+     's390x': ('s390x',),

+     'sh3': ('sh3',),

+     'sh4': ('sh4', 'sh4a'),

+     'sparc': ('sparc', 'sparc64', 'sparc64v', 'sparcv8', 'sparcv9',

+               'sparcv9v'),

+     'x86_64': ('x86_64', 'amd64', 'ia32e'),

+ })

+ 

+ 

+ def basearch(arch):

+     # :api

+     return _BASEARCH_MAP[arch]

+ 

+ 

+ # End bad things

  

  def _check_mock_grp():

      """Raise ReviewError unless mock installation is OK."""

This is ugly, but it's the first step on the road to being able to publish FedoraReview on PyPi. It also means you can work on FedoraReview in a venv without having to forward the system install of Python into it.

I'm very open to feedback on this, as it's the first PR in a series trying to modernise the Python toolchain in use, hopefully with the goal of creating something that can go on PyPi.

rebased onto f885b88

8 months ago

I don't think this is an acceptable thing to do. We already require rpm which is not in PyPI.

I also don't think there's much value in putting this in PyPI either.

I don’t think this is an acceptable thing to do

That’s fair enough. I raised this now so it could be shot down before I spent too much time on it.

We already require rpm which is not in PyPI.

Technically it is. The packit folks have claimed rpm on PyPi with https://github.com/packit/rpm-shim which does some hacky stuff to pull it into a venv from the system install. Their expectation is that you’d use that whilst developing, and use the real package when actually publishing. It’s not nice, but it’s good enough for when developing.

I also don't think there's much value in putting this in PyPI either.

Fair enough. We should probably close #345 in that case. I also think this is helpful for being able to do development in a venv.

As mentioned, I’m aware this is a tradeoff, and it’s not my decision to take. Personally I think this is worth doing to make development easier, but I’m not going to be hurt if you disagree and reject this change.