#4 Use libmodulemd2 get_profiles
Closed 4 years ago by athoscr. Opened 4 years ago by athoscr.
athoscr/flatpak-module-tools libmodulemd2  into  master

Use libmodulemd2 get_profiles
Athos Ribeiro • 4 years ago  
@@ -311,7 +311,7 @@ 

  

          # A runtime module must have a 'runtime' profile, but can have other

          # profiles for SDKs, minimal runtimes, etc.

-         self.runtime = 'runtime' in base_module.mmd.get_profile_names()

+         self.runtime = 'runtime' in base_module.mmd.get_profiles()

  

          if profile:

              self.profile = profile
@@ -320,7 +320,7 @@ 

          else:

              self.profile = 'default'

  

-         assert self.profile in base_module.mmd.get_profile_names()

+         assert self.profile in base_module.mmd.get_profiles()

  

      # The module for the Flatpak runtime that this app runs against

      @property
@@ -334,7 +334,7 @@ 

          for module_name in dependencies[0].get_buildtime_modules():

              try:

                  module = self.modules[module_name]

-                 if 'runtime' in module.mmd.get_profile_names():

+                 if 'runtime' in module.mmd.get_profiles():

                      return module

              except KeyError:

                  pass

get_profile_names bindings are not functional as of
module-build-service-2.24.0 and libmodulemd-2.6.0

Signed-off-by: Athos Ribeiro athoscr@fedoraproject.org

Hi,

Our OSBS atomic-reactor test suite started failing for the latest flatpak-module-tools release: https://github.com/containerbuildsystem/atomic-reactor/pull/1236

While we were installing the package from pypi, I kept hitting the same error in local tests, while using module-build-service-2.24.0 and libmodulemd-2.6.0: AttributeError: 'Module' object has no attribute 'get_profile_names'

When applying this patch, I still get error for the Dependency get_buildtime_modules(). Maybe I have the wrong version of some other lib?

Unfortunately, libmodulemd >= 2.0 has two incompatible api's ... You can
pick which one to use, but only one can be used in a python process. I
needed to switch flatpak-module-tools to use the real 2.0 API for
module-build-service compatibility. I think your patch is switching back
some portion hit by tests to the 1.0 API.

I have a patch for atomic-reactor to make it use the 2.0 api, but was
holding off on a PR until libmodulemd 2 is available in epel7.
https://bugzilla.redhat.com/show_bug.cgi?id=1724271

For now, the right thing to do, I think, is to specify flatpak-module-tools
< 0.10 in requirements-flatpak.txt. (I'm on vacation through Wednesday, or
would submit a proposal for that this morning)

Thanks for the reply, @otaylor!!!! Closing this PR!

Pull-Request has been closed by athoscr

4 years ago
Metadata