WIP: Generalize building of artifacts using classes

[darkmuggle]

This folds a lot of the copy-pasted buildextend code into a class.

[ashcrow]

Why not importlib: https://docs.python.org/3.6/library/importlib.html?

>>> import importlib            
>>> mod = importlib.import_module('os.path')                         
>>> print(mod)                  
<module 'posixpath' from '/usr/lib64/python3.7/posixpath.py'>
>>> import os.path              
>>> print(os.path)              
<module 'posixpath' from '/usr/lib64/python3.7/posixpath.py'>

[ashcrow]

nit: This may make sense at a higher scope.

[ashcrow]

NM this is the higher scope.

[ashcrow]

nit: This may make sense at a higher class.

[ashcrow]

Never mind... this is the higher class.

[ashcrow]

I feel like these should either move out of this module, or the module should be renamed from qemu to something more generic.

[ashcrow]

Thank you for starting this!!!

[cgwalters]

One recent trend in programming languages has been away from object orientation. While there are a few problem domains it matches really well (GUI programming), I think having good code organization (like Rust modules, Go packages) with basic procedures and interface types is generally better - more flexible, doesn't constrain one as much into thinking of "is-a" relationships.

Specifically for us, I think this code is a good example of when object orientation isn't a great fit - we have a list here of known subclasses.

And in general build software seems very much to me a problem domain that's procedural with functional parts.

That doesn't mean we don't create objects - Python clearly needs them, I just I think it'd be more natural to basically use classes as "structs with methods" - no inheritance. So e.g. the buildextend-aws would call build_image({ platformid: 'aws', 'image_suffix': 'vmdk'}) etc., and that may end up creating an ImageBuild struct with convenient parameters, but there wouldn't be subclassing.

That all said, this is definitely an improvement overall! So none of this is a blocker, just writing out my thoughts, and we should try to be sure we're aligned on future directions.

[cgwalters]

(Obviously, Python the language is heavily about objects so it's hard to avoid entirely, and doing so wouldn't be worth it! I just program in Rust and Go (and C) enough that I don't tend to think "subclass" unless the problem domain really really needs it)

[darkmuggle]

I appreciate the thought and the discussion, and I agree that having an interface over OOO would be nicer. While hacking on this I had similar thoughts, especially around the _Build Class.

Though, the feedback is valuable. I'm seeing a clear case where the VMWare OVA can become a subclass, but the others are weaker cases, especially when it amounts to settings some **kwargs

[cgwalters]

Are you planning on moving buildextend-metal into Python with this? If so let's be sure no one else is hacking on it at the time as it'll heavily conflict.