[Rpm-maint] [rpm-software-management/rpm] initial embedded python interpreter support (@rpm5.org derived) (#25)
notifications at github.com
Sat May 28 15:13:13 UTC 2016
I don't think making use of embedded python interpreter in scriptlets are particularly sane, especially considering python doesn't support separate self-contlained interpreter instances independent of each others in same process, it'll easily get too fragile ie. for use with such as dependency solvers written in python, which are only one amongst several issues speaking against it.
So I should trim down the amount of code and functionality considerably to make it less complex and tedious to maintain.
In a really small dlopened() module that provides support for embeddig python as an alternative/extension to regular rpm macros which has it's limitations (what made me decide fixing up python support in rpm5.org and put it to use in cooker was limitations to regular rpm macros, more specifically the one I couldn't work around, not supporting whitespace in arguments) and alternative to lua which I myself and probably a lot other packagers has less knowledge and experience with compared to python (which is generally the high level language of choice in our distro development world), while also by supporting keyword arguments with default values and also object orientation where especially inheritance makes templating an easy task.
A very complete standard python library also can easily come quite convenienly in handy.
One issue, and which I guess is related to others' concern and reluctance towads carrying this support upstream is that existing rpm plugin support doesn't support support plugin functionality for macro processor,and it's not immediately clear if to extend it, how to best do so...
This leaves non-standardized means of loading it as a separate module to avoid linking rpm against python library and pulling in python dependencies, where it would be the sole module loaded this way with dlopen()'ing it., which I guess could be the most acceptable to many in order avoid such dependencies.
Others would probably not mind if macro support only restricted only to building packages, considered as an "acceptable" dependency of rpm-build as most people installing & using rpm-build anyways are on a development system where the number of dependencies are less relevant, or at least if needing rpm-build for something, likely to already have python installed anyhow.
Then there's the good design principle of standardizing the functionality means of loading it, especially with the assumption by adding functionality through a module that needs to be loaded, it's plausible that other functionality provided through a module loaded the same way is made later for which a standard api for managing it certainly makes it preferable.
The latter would be the ideal solution, any suggestions/pointers on best approach? I'm still not all that familiar with rpm.org api and code anymore due to heavy refactoring over the years since I last had good overview with rpm 4.6, while not even followed up on my pull requests for a half year and need to refresh my knowledge of current code, so any thoughts/preferences would be greatly appreciated.
I certainly think this is functionality really important to support as:
* it would by make macro processor more powerful with a lot stuff more easily automized than through what the arcane rpm macro processor with it's horribly clumsy syntax for anything complex
* easier to do templating with specific types packages easier top create through use of where it could
be made as easy as just setting parameters unique to the the individual packages and where necessary adjust default parameters for template generating package
* templates could be easily customized to individual distributions packaging practices, hidden from packages using them in a single central place, making packaging efforts easier to share with template usage with parameters etc. remaining the same regardless of, increasing compatility of source rpms
* also maintaining and adopting new policies more rapidly by only having implement them in templates, automaically applied to packages by simply rebuilding packages without having to apply them to each individual package manually, having to relate to both various cosmetical differences for specs and different, often different ways of packaging same type of packages that could and should ideally stay as consistent and identical as possible
And for this to be made as relevant as possible, support for the functionality should be available from upstream.
In short, potential of creating new packages considerably easier, while reducing maintenance within a distro, with the possibility of further reducing the maintenance of same packages collectively across distros.
Any thoughts and views on/for/against this of interest for people to discuss?
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rpm-maint