#9 Use custom paths module
Closed 7 years ago by lsedlar. Opened 8 years ago by lsedlar.
lsedlar/pungi-fedora custom-paths  into  master

file added
+32
@@ -0,0 +1,32 @@ 

+ # -*- coding: utf-8 -*-

+ 

+ from pungi.paths import LogPaths        # noqa

+ from pungi.paths import WorkPaths       # noqa

+ from pungi.paths import ComposePaths as OriginalComposePaths

+ 

+ 

+ # Put ISOs from one variant and put them into another place. The value in the

+ # mapping should be a variant UID. However, no such variant needs to exist, but

+ # the paths will be used as if was a regular variant.

+ #

+ # The metadata will contain correct path to the ISO, but the image will be

+ # listed under its real variant.

+ MAPPING = {

+     'KDE': 'Live',

+ }

+ 

+ 

+ class DummyVariant(object):

+     def __init__(self, uid):

+         self.uid = uid

+         self.type = 'variant'

+ 

+ 

+ class ComposePaths(OriginalComposePaths):

+     def iso_dir(self, arch, variant, symlink_to=None, create_dir=True, relative=False):

+         try:

+             variant = DummyVariant(MAPPING[variant.uid])

+         except KeyError:

+             pass

+         return super(ComposePaths, self).iso_dir(

+             arch, variant, symlink_to=symlink_to, create_dir=create_dir, relative=relative)

file modified
+1
@@ -24,6 +24,7 @@ 

  ATOMICREPO="/mnt/koji/compose/atomic/$BRANCHED/"

  ATOMICDEST="/pub/fedora/linux/atomic/$BRANCHED/"

  OLDCOMPOSE_ID=$(cat $TARGET_DIR/latest-Fedora-/COMPOSE_ID)

+ PYTHONPATH=$(dirname $0)

  # uncomment and edit for resuming a failed compose

  #COMPOSE_ID="Fedora-23-20150530.n.0"

  

no initial comment

This only differs in where ISOs and images are placed: when the variant uid matches some known value, it will use a fake variant. This allows to put deliverables from multiple variants into a single directory.

To use, the module needs to be importable by python. Setting PYTHONPATH should be enough. The main configuration also needs to be updated with

paths_module = "fedora-paths"

The module needs to define a mapping from real variant to a (possibly fake) variant where the image should be put to. The images.json file will list the image under original variant, and the path will point to the correct location. Images from multiple real variants can go into the same destination.

For example, images from KDE variant should be stored in place where images from Live would go.

MAPPING = {
    'KDE': 'Live',
}

Okay, there is a problem with this approach – the checksum file with each file in the directory only lists images from single real variant. This would need to be fixed in the image checksum phase in pungi.

this seems basically fine to me, though the PYTHONPATH hack seems ugly, it'd be nice to have an 'official' place to put such custom modules, I guess.

I am happy with any solution which lets me conveniently answer the question "what is in this image", so long as it doesn't invalidate any other metadata and releng is happy with it.

I think I would like to see pungi gain the ability to have plugins, then this could be packaged and we can enable the plugin as needed. not all composes will need it.

If this was packaged and installed into /usr/lib/python2.7/site-packages/, there would be no need to change Pungi nor to specify the PYTHONPATH.

However I would prefer the payload version. Having some identification for the image itself would be useful even for pungi.

Yeah, in response to "I think I would like to see pungi gain the ability to have plugins".. I think pungi allowing you to set paths_module = "fedora-paths" constitutes having a plugin system -- that's a pluggable paths module.

Having it installed to the %{python2_sitelib} would do it, like @lsedlar says.

packaged plugins could eb in /usr/share/pungi/plugins/ or somewhere that we define as the location, witha configuration option to chose which plugins to enable

Just install the plugins in %{python2_sitelib}, and then we don't have to write more plugin handling code. The less we have of that (and the more that we just rely on the existing python import system) the better.

The number of python plugin systems that rely on the plugins living in the normal $PYTHONPATH is enormous.. they definitely outnumber the systems that rely on plugins living in /usr/share or some other place.

Anyway, since the original issue was solved by adding the subvariant field to metadata, I will close this pull request.

Pull-Request has been closed by lsedlar

7 years ago
Metadata