Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Not a Bug
    • None
    • N/A
    • burza

    Description

      Please, correct me if I understood the concept wrong. Or give me please an advice how to work with such cases correctly.

      Let's take a look at the plugins concept that we use in Burza.
      We use Pluggy

      Let's take a look at an example https://pluggy.readthedocs.io/en/stable/#how-does-it-work
      As we can see, we declare a hook and implement this particular hook in several places. And by calling a hook with a plugin manager we invoke all implementations of this hook in all places we declared it.

      Let's take a look in a real example (all names are abstracted).

      In Burza (almost) everything is a plugin.

      Suppose we have a hook with name `options_parsed`, the hook logic does something after the options are parsed.

      Let's work with a test suite (TestSuite). Suppose, we have two test suites. The first one (`TestSuite_1`) works with some specific logic (TestSuite1 does not know anything about TestSuite_2, they are different by definition, their components are different) and implements the hook `options_parsed` and its implementation requires us to provide some specific arguments (`arg1_a`, `arg1_b`, etc.) and if they were not provided an error is happening. The second one (`TestSuite_2`) does same thing: it has implementation of the hook `options_parsed` and implementation requires us to provide some specific arguments (`arg2_a`, `arg2_b`, etc.) and if they were not provided an error is happening.

      During the work I need to choose only one TestSuite from the list, and only one will be run.

      When the plugin manager calls the hook `options_parsed` both implementation are being called.
      In this case, if I chose to work with `TestSuite_1` and I provided all argument that this particular hook requires me to do. But `options_parsed` from `TestSuite_2` also is called and requires me to provide argument that I do not need at all (i.e. logic from another plugin is invoked which has nothing to do with the first plugin). And vise versa.

      Let's assume we have 10 TestCase plugins and all of them have implementation of `options_parsed` hook with different logic (because they are different and were created for different purposes). Hence, we need to worry about every arguments, errors, edge cases, etc. for every discovered TestCase plugin despite the fact that we only work with only one.

      It relates to almost all categories of plugins and hooks.

      My suggestion to handle such cases:

      • we have implemented base plugin classes for several plugin categories (TestCase, TestSuite, TestRunner, to name a few) and we want to reuse them because they are part of the app engine. But base classes have implemented hooks. I would remove all hook implementations from the base classes and put them into class implementations.
      • also, we search for plugins in many places at once and hence we may have many plugins of a particular type are being discovered. I would parametrize discovering of the plugins to not have duplicates for specific plugin categories.
      • also, if we update plugins discovery in such way it may help us to not have many excessive options in `help`

      What do you think about it?
      What we can do with it?

      Attachments

        Activity

          I received some detail about the codebase and the issue is not to be exist anymore.

          Closing.

          konstantin_k Konstantin Kovalev added a comment - I received some detail about the codebase and the issue is not to be exist anymore. Closing.

          People

            konstantin_k Konstantin Kovalev
            konstantin_k Konstantin Kovalev
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.