metwork-framework / mfplugin Goto Github PK

View Code? Open in Web Editor NEW

0.0 3.0 1.0 107 KB

the metwork plugin api and tools in a dedicated repository

License: BSD 3-Clause "New" or "Revised" License

Makefile 0.29% Python 99.71%

integration-level-3 autoreadme github-actions

mfplugin's Introduction

mfplugin

Status (master branch)

What is it?

The metwork plugin api and tools in a dedicated repository (experiment)

Contributing guide

See CONTRIBUTING.md file.

Code of Conduct

See CODE_OF_CONDUCT.md file.

mfplugin's People

Contributors

Watchers

Forkers

albator75

mfplugin's Issues

plugin config is removed even if something has been changed into it

In the finally clause of mfplugin/cli_tools/plugins_uninstall.py, the plugin config file is removed in any case :

finally:
        try:
            os.unlink(f"{MFMODULE_RUNTIME_HOME}/config/plugins/{name}.ini")
        except Exception:
            pass

whereas in _remove_plugin_config.py (called before by _plugins.preuninstall <- _preuninstall_plugin <- uninstall_plugin) this same file is removed ony if "nothing has been changed" into it :

target = "%s/config/plugins/%s.ini" % (MFMODULE_RUNTIME_HOME,
                                           args.PLUGIN_NAME)

    if os.path.exists(target):
        if not has_an_interesting_line(target):
            # There is a configuration file but nothing has been changed
            # so we can unlink it!
            try:
                os.unlink(target)
            except Exception as e:
                LOGGER.warning("can't unlink: %s with message: %s" %
                               (target, e))
        else:
            # We prefer to keep it as there are some changes in it!
            pass

Solution : remove the finally clause

postinstall - no trace during installation/make develop

In manager.py, method _postinstall_plugin, the command _plugins.postinstall is called as shell script.
It results that not standard output shown to the user when installing/make_developing the plugin.

It's very annoying to not be aware of postinstall execution. Especially when important commands are run into it... or when the postinstall script takes a long time.

Note: a # FIXME: should be python methods and not shell is present in the file

Example with adding datetime:

[mfserv:~/my_plugin]↥ develop ± make develop
- Checking plugin...                                       [ OK ]              
- Devlinking plugin my_plugin...               [ RUNNING ]   
start;16/01/2023 17:49:13
                                                           [ OK ] 
end:16/01/2023 17:51:14

Can't manage to add release version to plugin name during make release

The idea is to retrieve release version from .metadata.json file. While this is not possible, because the current implementation looks for this json file in ~/metwork/mfmodule/var/plugins when plugin is not installed.
The thing is, during make release the release version is always fixed to 1:

mfplugin/mfplugin/plugin.py

Line 210 in eab633a

def _load_version_release(self):

So, the problem is, when the plugin is not installed, the file can't exist in ~/metwork/mfmodule/var/plugins, and what we want is to look up for this file in the current dir where the make release is executed, so that we can extract the release version and concatenate it at the end of released plugin.

Other solution that could be intersting is to read the release version from an environment variable.

Encoding issue with singletable from python terminaltables

Hello,

Singletable from python terminaltables is displayed as below :

^(0l^(BInstalled plugins (1)^(0qqqqwqqqqqqqqqwqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk^(B
^(0x^(B Name          ^(0x^(B Version ^(0x^(B Release ^(0x^(B Home                                   ^(0x^(B
^(0tqqqqqqqqqqqqqqqnqqqqqqqqqnqqqqqqqqqnqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqu^(B
^(0x^(B my_plugin ^(0x^(B 2.0.5   ^(0x^(B 1       ^(0x^(B /home/mfserv/var/plugins/my_plugin ^(0x^(B
^(0mqqqqqqqqqqqqqqqvqqqqqqqqqvqqqqqqqqqvqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj^(B

At least :

on gitlab CI job terminal
while executing watch plugins.list on CentOS7

The configuration variants in the config.ini file according to the machine profile do not work

To configure the plugins it is possible to put your own configuration keys in the config.ini file of the plugin in the configuration group [custom]
In addition it is possible to use configuration variants in this file according to the machine profile (DEV, INT and OPER) as specified in the documentation of the opinionated_configparser library (https://github.com/metwork-framework/opinionated_configparser /blob/master/README.md) by specifying the profile of the machine in the /etc/metwork.config file
So that's what I did
In my /etc/metwork.config file we find DEV_PIPOUF
In the config.ini file of my plugin

[custom]
# header transmits mobile user
header_transmet_mobinaute = SFFR90LFPW
entete_transmet_mobinaute [DEV] = SFFR91LFPW
entete_transmet_mobinaute [DEV_PIPOUF] = SFFR92LFPW

then

Welcome on vmdevcentos6 (vmdevcentos6.ad.meteo.fr, None)
(module: MFDATA, config: DEV_PIPOUF, version: 1.0.2)

 15:33:07 up 19:44, 14 users, load average: 0.23, 0.12, 0.03

⌁MFDATA⌁ [joel: ~ / work / gitlab] $ plugin_wrapper obsparticipative - env | grep MFDATA_CURRENT_PLUGIN_CUSTOM_ENTETE
MFDATA_CURRENT_PLUGIN_CUSTOM_ENTETE_TRANSMET_MOBINAUTE = SFFR90LFPW

It seems to me that I should have found SFFR92LFPW

problem with releaseignore file (files are not excluded)

uninstall plugin with path

For "dummies", allow plugins.uninstall to be called with plugin path, example:

# very common mistake
plugins.uninstall my_plugin/
# other possibilities
plugins.uninstall ~/my_plugin/
plugins.uninstall ~/my_plugin
plugins.uninstall ../my_plugin/
plugins.uninstall ../my_plugin
plugins.uninstall ./my_plugin/
plugins.uninstall ./my_plugin
plugins.uninstall /home/mfserv/my_plugin/
plugins.uninstall /home/mfserv/my_plugin
plugins.uninstall /home/mfserv/var/plugin/my_plugin/
plugins.uninstall /home/mfserv/var/plugin/my_plugin

reason: using [tab] to have the plugin name is a common usage but it adds the / after the plugin name (as it is a directory)