Related: #193

the test_runroot.py test is failing

Yeah, the global injection seems a little heavy handed. Surely there is a better way. Granted that may mean moving more code around.

I did so - koji_cli module created. koji_cli.lib contains all reused functions, while koji_cli.commands contains all default commands. Import of commands is now via 'normal' import and plugins will behave almost exactly as standard commands.
Also tests were little bit simplified as there is no need to do magic of loading koji 'binary'.

Why are plugins being installed to /usr/lib/koji-cli-plugins? If they're executable scripts called upon by Koji, shouldn't they default to /usr/libexec/koji/cli-plugins or something like that? Alternatively, if they could be treated as functionality equivalent to regular python imports, then they could be in %{python_sitelib}/koji-cli-plugins instead?

My reasoning was to be coherent with how koji-hub-plugins and koji-builder-plugins are handled. But yes, you're right and pyhon_sitelib would be more appropriate place.
@mikem is there any reason to stay with these 'old' paths? Or could we move all these three to sitelib?

@tkopecek I would support moving them to sitelib and treating them like regular imports. Let's not be special if we don't have to be.

Plugins moved to {sitelib}/koji_cli_plugins, build scripts updated.

rebased to master and fixed test which appeared meanwhile

Should I rebase it to current master, or are there some more design comments?

I would also like to make commands a module instead of one (still big) file. But I've never seen rationale for having all of it in one file (same for kojid). So, is there any, or could we go kobo way - one file per command in commands module?

I would also like to make commands a module instead of one (still big) file. But I've never seen rationale for having all of it in one file (same for kojid). So, is there any, or could we go kobo way - one file per command in commands module?

I don't think there's an intrinsic reason or anything.

If we go to separate files, then seems like we'd only want to import them on demand. I suspect if we're going to import all of it, it's probably faster as one file.

If we do import them on demand, then we have to sort out just how that will work. The help command will probably need to load them all, but the rest should only need to load themselves.

Loading just the command we need means we need to know in advance where to load it from, which suggests that the file/module name should be derived from the command name.

Need to fix the Makefile changes to use tabs, make is complaining

...except the ifneq/endif lines, those need to not be indented I think (otherwise make install fails)

default value of plugins means that command fails at start if koji-cli-plugins is not installed.

Having pluginpath and plugins in read_config(), which lives in the main lib and is used by other tools, seems questionable. This isn't just for the cli anymore.

This is a tricky issue. I'm not sure what the best answer is here.

To pluginpath: Other options could be to have separate koji cli config, section in koji.conf [cli] or leave it as it is. Also not sure.

• split_cli script used for initial split instead of manual work
• updated to python3 structure
• activate_session has easier changes (options -> goptions if needed)
• all tests passing

@mikem - one more thought about configuration. Option could be to don't make it configurable. It would differ from hub/builder, but on the other side, every plugin should fail correctly if it is not supported on hub. So, everything found in site-packages/koji_cli_plugins would be loaded and no other (or predefined path in home directory) and nothing more. Would it be better?

Installed package fails to run because the python3 lib doesn't include koji.plugin. Fix here

https://github.com/mikem23/koji-playground/commits/issue193

Afew more fixes on the branch linked above. Some are more general py3 fixes that I ran across while testing.

Added your commits + typo fix in rewritten plugin search.

Commit 9cfadf75 fixes this pull-request