Plugin compatibility in Plugin Manager

Plugins
1

While the Plugin Repository has compatibility information (specifically Python compatibility), this information is not visible in the Plugin Manager within OctoPrint itself. I believe the Plugin Manager uses this information, but I think it would be useful if it was displayed for the user.

If I only had to do it once, looking up each 3rd party plugin I have (about 20) in the repository wouldn't be too bad, but monitoring the progress towards being able to switch to Python 3 would require repeating this process numerous times. I prefer that the manager do this for me.

2

A short-term work-around would be to farm the plugins.json feed.

3

While work-arounds can be developed, I think adding this to the Plugin Manager is a nice, clean, (and hopefully simple) solution.

4

I think I might create a python3 plugin compatibility check plugin for you guys. I could see where this might start to be getting more and more of a question. Stand By...

2 Likes
5

Ok, try this one. I think it works. It pulls the plugin list feed, compares against installed plugins and returns a list of links to the plugin's homepage for those that don't have a compatibility.python string that includes the text <4. If anyone knows a better javascript function for including compatibility strings that are like >2,<3.8 I'd be happy to make that change. The relevant line in code is here.

Install using the URL below in Plugin Manager.

https://github.com/jneilliii/OctoPrint-Python3PluginCompatibilityCheck/archive/master.zip

2 Likes
6

I'd recommend that foosel bundle this one for a bit.

7

@jneilliii Thanks for the plugin.
@OutsourcedGuru Rather than bundle a plugin, I'm still really lobbying for @foosel to add something to the Plugin Manager.

8

It's quicker to get a plugin out than it is an octoprint upgrade, but that's up to Gina. I've submitted the plugin to the plugin repo, awaiting approval/merging.

9

What about a post here that tracks plugin compatibility and ages? I assume jniel's foo could easily do that, otherwise I can write a quick parser.

10

I think @OutsourcedGuru had done something like this in another post, or at least gave guidance. I'm not sure how you would calculate age, because I think the only date in the plugin repo is the original submission date.

11

I'll see what Guru says, but I can fetch some metadata from GitHub to guess at the age.

12

Yeah, I noticed a feature request on the plugin repo for similar metadata scraping.

1 Like
13

I just pushed an update to the plugin that will also attempt to scrape the date the listed plugins were last pushed to. This of course will only work with Github repositories and there is a rate limit of 60 requests per hour for a non-authenticated request the way I'm doing it.

image

@tedder42, BTW I was wondering if you've had a chance to really test the MQTT plugin for compatibility yet? I haven't run into any issues with my forced_compatible flag that I've seen but haven't really dug deep into it.

14

I finally upgraded my printers, had been ignoring them for a bit. I'll take a look.

15

Not in JS, but you could enrich the retrieved information with a call to octoprint.util.is_python_compatible:

plugins = webresponse.json()
for entry in plugins:
    to_check = entry.get("compatibility", dict()).get("python", ">=2.7,<3")
    entry["python_compat"] = octoprint.util.is_python_compatible(to_check, python_version="3.6")
return plugins

Do you want to take a look at this first before I merge it?

Gotta admit, I wish I could that as easily in the jekyll code used for serving the repository webpages, I'm currently simply doing string searches and it really makes me unhappy ^^

Making the compatibility information visible in the repository browser indeed makes sense (not only python, but also the OS and such), I'll get on it.

16

Hi all,

the plugins.json doesn't include the truth. E.g. in the screenshot above my DLP-Plugin is listed, because the plugin-repository information is not up to date. But the DLP-plugin works with python 3 and OP1.4.

IMHO: We need to improve the content of the plugins.json and not an additional plugin (don't get me wrong, the "Python3PluginCompatibilityCheck-Plugin" is helpful, but it is just a workaround)

Why not executing a shell-, nodejs-, python- or ruby-script to crawl the compatibility-information, before executing Jekyll.

script:
- python grapCompatibility.py
- bundle exec jekyll build

The script look into each single plugin-repository, parse the __init__.py file for compatibility-information (beside python, just add the other stuff, like OP-, OS-Version) and build the plugin.json file with that information.
Just add some default behaviour, if not all compatibility-information could be selected. Just grab the info from the plugin-markdown (but add a hint about the source of the information).
In the future the markdown compatibility-information should be deprecated.

Is this to complicated or did I missed something? (For 60request/h limit, we need to switch to auth-user, then we have 5000request/h) see https://developer.github.com/v3/#rate-limiting

What do you think?

17

@jneilliii Until this plugin is approved, updating seems to be just installing again from the posted URL. Am I correct?

I believe we are converging on the best possible solution. A short-term, very useful, plugin and a longer-term, probably enhanced, solution in the OctoPrint core.

Since I have one of my own plugins on the list, I'm motivated to get it off. The "oldest" one on my list is DisplayZ owned by none other than our fearless leader. I've looked at the plugin and I think the only change required is to add the compatibility string.

18

Yes, or in software update section of octoprint force a check for updates under the advanced options at the bottom.

19

Well, that would be here and here but it sounds like jneiliii's already done pretty much the same (minus the NodeJS).

20

@OllisGit, Why don't you fix that by submitting the correct information to the plugin repository? If you don't people will never find it in the Plugin Manager in the future anyway.

@foosel, I think it would be better to go ahead and get this merged and I'll investigate this option for a future version update. Need to figure out the best approach for supplying the Python version to check against, probably as part of the API call to the server side. That is of course, unless you decide to do something quick for the Plugin Manager and there is no need for this plugin at all.

1 Like