Apache Cordova
  1. Apache Cordova
  2. CB-4494

"plugman info pluginID" should display extended info about plugin

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.1.0
    • Component/s: Plugman
    • Labels:
      None

      Description

      I don't think we should filter by your platform, but it would be nice is we had some sort of indicator that showed which results were compatible vs not compatible.

      To do this, we'd need <engine> version info available in the couchdb schema I think.

      Step 1 to this bug is to design, Step 2 is to implement.

        Issue Links

          Activity

          Hide
          Tim Kim added a comment -

          Hey all,

          I think this is a cool feature but I'm unsure how the check against your configuration would work. With the exception of the cordova-plugman engine, all the other engines (ie, cordova, cordova-ios/android/blackberry etc...) need to execute a version script within the platform directory. However, plugman is supposed to agnostic about the platform directories and it's more of the cli's job to know about that directory in the first place.

          Furthermore, in the case of a custom engine, the version script for the custom engine is to be placed within the plugin's folder so that would mean that having the <engine> version info wouldn't be enough. A user must download the plugin first, run the custom engine version script within the plugin folder, and then determine if it's compatible or not.

          Show
          Tim Kim added a comment - Hey all, I think this is a cool feature but I'm unsure how the check against your configuration would work. With the exception of the cordova-plugman engine, all the other engines (ie, cordova, cordova-ios/android/blackberry etc...) need to execute a version script within the platform directory. However, plugman is supposed to agnostic about the platform directories and it's more of the cli's job to know about that directory in the first place. Furthermore, in the case of a custom engine, the version script for the custom engine is to be placed within the plugin's folder so that would mean that having the <engine> version info wouldn't be enough. A user must download the plugin first, run the custom engine version script within the plugin folder, and then determine if it's compatible or not.
          Hide
          Anis Kadri added a comment -

          After discussing this issue with Tim Kim we came up with the following conclusions

          • Search can't tell if your configuration is compatible because your configuration is project based (not system wide) and users can have multiple projects with different Cordova versions. Unless they specify which project their 'search' command applies to (which is overkill) we can't show the right results for them.
          • Install should fail if the plugin's required Cordova version (as specified by <engine> in plugin.xml) is not compatible with the project's Cordova version and this is defined in CB-4036.

          What we can implement however is displaying the Cordova version (therefore storing <engine> in the registry) when users search for plugins. Andrew Grieve does that sound reasonable to you ? if so, we should update this ticket.

          Show
          Anis Kadri added a comment - After discussing this issue with Tim Kim we came up with the following conclusions Search can't tell if your configuration is compatible because your configuration is project based (not system wide) and users can have multiple projects with different Cordova versions. Unless they specify which project their 'search' command applies to (which is overkill) we can't show the right results for them. Install should fail if the plugin's required Cordova version (as specified by <engine> in plugin.xml) is not compatible with the project's Cordova version and this is defined in CB-4036 . What we can implement however is displaying the Cordova version (therefore storing <engine> in the registry) when users search for plugins. Andrew Grieve does that sound reasonable to you ? if so, we should update this ticket.
          Hide
          Andrew Grieve added a comment -

          The main motive behind this request is to address this scenario:

          • You have a project that has platform repos at version 3.0
          • We release cordova-cli v3.1, 3.2
          • When we release 3.2, we also made a backwards-incompatible change in Android, bumping the MAJOR semver component of cordova-android to 4.0
          • We then update the core plugins to require cordova-android 4.0, and bump the major version of the plugins

          In this case, it should be possible for `plugman` to answer:
          1. What is the latest version of a plugin?
          2. What is the latest version of a plugin that is compatible with my environment?

          Maybe `plugman search` is not the command for this though? Maybe we need a `plugman info`?

          I think it's fine to have feed the environment info into plugman, at least when run through CLI. CLI knows all the info and can pass it along. In the case of custom <engine> checks though, there's not much we can do.

          I'm also thinking that this doesn't have to be a pre-req to launching. What should be a re-req, is just a plan, e.g. so that the versions are put in the couch db for when we need them later.

          Show
          Andrew Grieve added a comment - The main motive behind this request is to address this scenario: You have a project that has platform repos at version 3.0 We release cordova-cli v3.1, 3.2 When we release 3.2, we also made a backwards-incompatible change in Android, bumping the MAJOR semver component of cordova-android to 4.0 We then update the core plugins to require cordova-android 4.0, and bump the major version of the plugins In this case, it should be possible for `plugman` to answer: 1. What is the latest version of a plugin? 2. What is the latest version of a plugin that is compatible with my environment? Maybe `plugman search` is not the command for this though? Maybe we need a `plugman info`? I think it's fine to have feed the environment info into plugman, at least when run through CLI. CLI knows all the info and can pass it along. In the case of custom <engine> checks though, there's not much we can do. I'm also thinking that this doesn't have to be a pre-req to launching. What should be a re-req, is just a plan, e.g. so that the versions are put in the couch db for when we need them later.
          Hide
          Anis Kadri added a comment -

          I updated the ticket to reflect your comments.

          I figured this would be more of a CLI use-case.

          plugman can store the <engine> data into the registry for easy querying later.

          plugman info io.cordova.dummyplugin
          latest version: 0.0.1
          cordova version: >3.1.0
          

          For each published plugin version you would have a matching Cordova version.

          How does that sound ? If it works, I can start working on this small feature.

          Show
          Anis Kadri added a comment - I updated the ticket to reflect your comments. I figured this would be more of a CLI use-case. plugman can store the <engine> data into the registry for easy querying later. plugman info io.cordova.dummyplugin latest version: 0.0.1 cordova version: >3.1.0 For each published plugin version you would have a matching Cordova version. How does that sound ? If it works, I can start working on this small feature.
          Hide
          Andrew Grieve added a comment -

          Sounds great!

          Just to clarify - there are currently multiple versions to store (CB-4490).

          Show
          Andrew Grieve added a comment - Sounds great! Just to clarify - there are currently multiple versions to store ( CB-4490 ).
          Hide
          ASF subversion and git services added a comment -

          Commit 07d2a49edb26e7e91ec30e6681218e476bb31068 in branch refs/heads/master from Anis Kadri
          [ https://git-wip-us.apache.org/repos/asf?p=cordova-plugman.git;h=07d2a49 ]

          CB-4494 adding info command and storing engine data in registry

          Show
          ASF subversion and git services added a comment - Commit 07d2a49edb26e7e91ec30e6681218e476bb31068 in branch refs/heads/master from Anis Kadri [ https://git-wip-us.apache.org/repos/asf?p=cordova-plugman.git;h=07d2a49 ] CB-4494 adding info command and storing engine data in registry

            People

            • Assignee:
              Anis Kadri
              Reporter:
              Andrew Grieve
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development