2018-07-02, 18:30
@docwra Thanks
2018-07-02, 18:48
Update - Week 10
1) PR #97 - update dependency ignore list: In the starting it was just a small pull for updating an ignore list but then we decided to implement an improved version of `ignore list`. Now we get a ignore list based on kodi's version i.e leia, krypton etc
This was done because there were some dependencies that weren't present in all the version but were causing false positive results for some version like "script.module.pycryptodome" etc
2) PR #98 - Add pylint check: Finally I have made some progress with our pylint checks. Currently I have implemented a rough version of these pylint checks. This version of check test for every possible error in code without skipping/ignoring any error.
We still have to decide what all error we want our "pylint checker" to look for in addons.
Also this PR won't be merged until we get a new version of pylint available for everyone and I am not sure when that will be because I haven't got any reply from @PCManticore so I am still stuck with the tests.
Plan for coming week:
1) Have a discuss with mentors about all the feature we want in "pylint check" and implement them.
2) Start work with radon checks.
3) Try to successfully write those pylint tests and get a new pylint version out.
1) PR #97 - update dependency ignore list: In the starting it was just a small pull for updating an ignore list but then we decided to implement an improved version of `ignore list`. Now we get a ignore list based on kodi's version i.e leia, krypton etc
This was done because there were some dependencies that weren't present in all the version but were causing false positive results for some version like "script.module.pycryptodome" etc
2) PR #98 - Add pylint check: Finally I have made some progress with our pylint checks. Currently I have implemented a rough version of these pylint checks. This version of check test for every possible error in code without skipping/ignoring any error.
We still have to decide what all error we want our "pylint checker" to look for in addons.
Also this PR won't be merged until we get a new version of pylint available for everyone and I am not sure when that will be because I haven't got any reply from @PCManticore so I am still stuck with the tests.
Plan for coming week:
1) Have a discuss with mentors about all the feature we want in "pylint check" and implement them.
2) Start work with radon checks.
3) Try to successfully write those pylint tests and get a new pylint version out.
2018-07-09, 19:39
Update - Week 11
1) PR #99 - @Razze pointed out that we should shift to pipenv. So I worked on setting up pipenv for our tool. Thanks to @Rechi for helping with the make file.
The work is completely done in this PR but the reason it isn't merged is that we are still trying to figure out that whether our tool is an application or is a package. Because it can't be both but it seems like it is
2) PR #98 - Add pylint check - After discussion about what all type of error we want from pylint integration and the way we want the output to be displayed, I completed the work on this integration.
But still this PR can't be merged because we still haven't got the new pylint version
Plans for coming week:
1) Complete work on radon integration
2) I tried a lot but couldn't get those pylint test fixed so I'll try again to get those test.
3) Also I plan to start writing test for our code-base.
1) PR #99 - @Razze pointed out that we should shift to pipenv. So I worked on setting up pipenv for our tool. Thanks to @Rechi for helping with the make file.
The work is completely done in this PR but the reason it isn't merged is that we are still trying to figure out that whether our tool is an application or is a package. Because it can't be both but it seems like it is
2) PR #98 - Add pylint check - After discussion about what all type of error we want from pylint integration and the way we want the output to be displayed, I completed the work on this integration.
But still this PR can't be merged because we still haven't got the new pylint version
Plans for coming week:
1) Complete work on radon integration
2) I tried a lot but couldn't get those pylint test fixed so I'll try again to get those test.
3) Also I plan to start writing test for our code-base.
2018-07-16, 17:09
[Update - Week 12]
1) PR #99 - add support for pipenv: we decided that we don't want pipenv right now for our tool so this PR is closed now.
2) PR #100 - Add check for python3 compatibility: These check will help us to check whether the addon is compatible with python3 or not. This will also help in porting addons from python2 to python3.
Currently the output format for report the these type of errors is a table format but we plan to improve it.
3) No update on pylint - I haven't done any work on the pylint side and doesn't plan to do it anytime this week.
In my last report I said that I'll be working on `radon integration` but I did py3_compatibilty and now after discussion we have decided that radon integration won't be much helpful.
So now in place of working on radon integration I am going to work on one of my old PR #35 (Schema).
Having schema validation will be more useful for us because than most of the checks will be handled just by having schema validation.
1) PR #99 - add support for pipenv: we decided that we don't want pipenv right now for our tool so this PR is closed now.
2) PR #100 - Add check for python3 compatibility: These check will help us to check whether the addon is compatible with python3 or not. This will also help in porting addons from python2 to python3.
Currently the output format for report the these type of errors is a table format but we plan to improve it.
3) No update on pylint - I haven't done any work on the pylint side and doesn't plan to do it anytime this week.
In my last report I said that I'll be working on `radon integration` but I did py3_compatibilty and now after discussion we have decided that radon integration won't be much helpful.
So now in place of working on radon integration I am going to work on one of my old PR #35 (Schema).
Having schema validation will be more useful for us because than most of the checks will be handled just by having schema validation.
2018-07-16, 18:32
Any plans for a GUI or web Front End for this project in the future?
Scripts are a great start but hardly user friendly for moderators or reviewers. Let alone for developers who wish to check their Add-ons before submission.
If you look at what business app stores do for their moderation processes, they will generally be web or app based.
Scripts are a great start but hardly user friendly for moderators or reviewers. Let alone for developers who wish to check their Add-ons before submission.
If you look at what business app stores do for their moderation processes, they will generally be web or app based.
2018-07-16, 22:14
It can be easily run with travis CI, see https://github.com/xbmc/addon-check/blob...ml.example.
2018-07-23, 20:27
[Update - Week 13]
This whole week I was working on schema validation: PR #35
Currently we have schema that are not completed meaning they only have whats inside the extension point elements i.e elements for plugins, metadata, scripts etc. They are not complete for validation with any XML file because it need to have root element i.e addon and other things.
After discussion we planned to had a single schema that will do the validation for all the addon types i.e plugin, scipts etc for that I generated a schema that will validate three type of addons - scripts, plugins and resource. That schema was generated by feeding addon.xml files from addon to a tool called `Trang`.
After further discussion we realized that generating a totally new schema from addon.xml files will not be optimal because
1) There will be missing attributes and lots of other thing we don't want.
2) The existing XSD file are present in kodi's source tree so whenever the schema changes we'll have to update a big schema. so having a new schema is not a good option.
After seeing all this issues with totally new schema we planned to have a global schema that will be dependent on other existing addon meaning there will be a schema that will have a root element with some other elements and for any extension point it will include an existing addon.
Now this approach also have a problem - All the existing schema have similar element type, if we include all those schema in single schema then it will be difficult to refer to any specific extension point.
We are still to solve this issue.
Plan for coming week: I will continue my work on the schema validation.
This whole week I was working on schema validation: PR #35
Currently we have schema that are not completed meaning they only have whats inside the extension point elements i.e elements for plugins, metadata, scripts etc. They are not complete for validation with any XML file because it need to have root element i.e addon and other things.
After discussion we planned to had a single schema that will do the validation for all the addon types i.e plugin, scipts etc for that I generated a schema that will validate three type of addons - scripts, plugins and resource. That schema was generated by feeding addon.xml files from addon to a tool called `Trang`.
After further discussion we realized that generating a totally new schema from addon.xml files will not be optimal because
1) There will be missing attributes and lots of other thing we don't want.
2) The existing XSD file are present in kodi's source tree so whenever the schema changes we'll have to update a big schema. so having a new schema is not a good option.
After seeing all this issues with totally new schema we planned to have a global schema that will be dependent on other existing addon meaning there will be a schema that will have a root element with some other elements and for any extension point it will include an existing addon.
Now this approach also have a problem - All the existing schema have similar element type, if we include all those schema in single schema then it will be difficult to refer to any specific extension point.
We are still to solve this issue.
Plan for coming week: I will continue my work on the schema validation.
2018-07-30, 18:03
[Update - Week 14]
Last week we were struggling with having a single massive schema for all the extension point and not being able to include all the existing extension-point schema files. But after looking into the problem we found out that there's no way to over come(see pull/35/comment) so we decided to leave the plan of having a singular schema and decided to follow a `step-by-step` validation process for schema.
The `step-by-step` method is:
1) User provides an addon.xml
2) we parse the xml, “remove” any `<extension>` elements that are child of `<addon>` and store them
3) we validate the resulting xml against a schema only having root elements i.e addon.xsd
4) Then we validate all the extension elements against each individual schema (depending on the type of extension element)
This method is implemented in PR #35 and the PR is under reviewing process.
plan for coming week:
1) Will be implementing a new check i.e Check if the `xbmc.python` version matches the one targeting the repository of the submission if not then raise a warning.
2) Write Unittest for our existing codebase.
Last week we were struggling with having a single massive schema for all the extension point and not being able to include all the existing extension-point schema files. But after looking into the problem we found out that there's no way to over come(see pull/35/comment) so we decided to leave the plan of having a singular schema and decided to follow a `step-by-step` validation process for schema.
The `step-by-step` method is:
1) User provides an addon.xml
2) we parse the xml, “remove” any `<extension>` elements that are child of `<addon>` and store them
3) we validate the resulting xml against a schema only having root elements i.e addon.xsd
4) Then we validate all the extension elements against each individual schema (depending on the type of extension element)
This method is implemented in PR #35 and the PR is under reviewing process.
plan for coming week:
1) Will be implementing a new check i.e Check if the `xbmc.python` version matches the one targeting the repository of the submission if not then raise a warning.
2) Write Unittest for our existing codebase.
2018-08-06, 19:54
[Update - Week 15]
1) The PR #35 is still under review because @enen92 updated some schemas under kodi so I also had to make those changes in our schemas. Also we have now named our schemas according to the kodi versions like gotham_repository.xsd or isengard_contextitem.xsd because we were having some issue with version dependent XML specifically with contextitem.xsd, schema for this was different for isengard and above version (https://kodi.wiki/view/Context_Item_Add-ons). So we had to rename the current schema to gotham_contextitem.xsd and @enen92 provided a new schema for isengard_contextitem.xsd
2) Created PR #103 - Add check for xbmc.python version: It checks the xbmc.python version used in addon.xml according to kodi version. Currently it only checks xbmc.python but the list can be expanded to add check for any module present in addon.xml
3) Most of the time I was working on writing my final report for work submission. For the first few days I was totally confused on what to write and how to write but somehow I managed to do it. Thanks to @enen92 for reviewing my report.
1) The PR #35 is still under review because @enen92 updated some schemas under kodi so I also had to make those changes in our schemas. Also we have now named our schemas according to the kodi versions like gotham_repository.xsd or isengard_contextitem.xsd because we were having some issue with version dependent XML specifically with contextitem.xsd, schema for this was different for isengard and above version (https://kodi.wiki/view/Context_Item_Add-ons). So we had to rename the current schema to gotham_contextitem.xsd and @enen92 provided a new schema for isengard_contextitem.xsd
2) Created PR #103 - Add check for xbmc.python version: It checks the xbmc.python version used in addon.xml according to kodi version. Currently it only checks xbmc.python but the list can be expanded to add check for any module present in addon.xml
3) Most of the time I was working on writing my final report for work submission. For the first few days I was totally confused on what to write and how to write but somehow I managed to do it. Thanks to @enen92 for reviewing my report.
