Jython VsCode and pylint

Tags: #<Tag:0x00007fc201a42f20> #<Tag:0x00007fc201a42de0> #<Tag:0x00007fc201a42ca0>

Hi there,
Me again
All is well and the rule transfer going well
However I get these in VSCode:

I have followed this: https://openhab-scripters.github.io/openhab-helper-libraries/Getting%20Started/VS%20Code.html

And saw this:

To no avail

Any advice?

Unfortunately I’ve never seen these errors and now I’m not certain that I even have pylint properly configured. :frowning: When I add stuff that it should pick up like “import foo” I don’t get any problems.

Are you by any chance editing using the Remote SSH extension? I thought I had it set up properly all this time.

Nope, just following this: https://openhab-scripters.github.io/openhab-helper-libraries/Getting%20Started/VS%20Code.html

I’ll try a fresh vscode install tomorrow

Everything underlined that I can see is a Java package, or part of the default script environment. These things are only available when running in the Jython environment inside openHAB unfortunately, you will not be able to resolve them. There should be a note on the instructions saying that things from the Java/openHAB scope are not available.

Hi all,

Any ideas for improving the JSR223 experience in vscode are welcome.
We have already a (really old) corresponding issue in github which i revived last days.

We have talked about general improvements and things we could add, like snippets for jythong and javascript.
There is also the posibility to use items and things browser now, when having jsr223 files opened.
The sidebar will be available permanently from now on.
You can test this with the current beta extension.

So if there are additional things that would be useful and we can solve that within the extension we should add it to the list.

I don’t know much about how VSC extensions work, but this problem is caused by pylint (an external program run by VSC in the background) not having access to the default script context. I’m not sure the VSC extension would be able to help here, though I hope I’m wrong about it because it would be handy.

google pylint and jython - I found several posts but not an obvious answer.

Vincent, sorry I did not have time to reply sooner. What you are reporting looks normal to me. I use a .pylintrc file and I’ll put in a PR tommorow to add one to the repo. Until then, add one to the root of your workspace with this as the contents…

[MESSAGES CONTROL]
disable=
    missing-docstring,
    unused-variable,
    line-too-long,
    logging-format-interpolation,
    bare-except,
    broad-except,
    pointless-string-statement,
    undefined-variable,
    unused-argument,
    wrong-import-position,
    anomalous-unicode-escape-in-string,
    global-statement

ignored-modules=
    org.joda.time,
    java,
    core,
    core.jsr223,
    core.actions,
    community,
    personal,
    configuration,
    events

[DESIGN]
# Maximum number of parents for a class (see R0901).
max-parents=15

There may be some other entries that we’d want to include, but these resolved all of the issues I had.

3 Likes

@openhab-5iver is it wise to suggest the use of ignored like unused-variable and undefined-variable in the documentation? I feel like the latter at least is most helpful to beginners, but using it is how you would suppress the error coming up for something common like the items dict.

I have no detailled knowledge about this case, but that doesn’t mean that we can’t have a look at it.

My post was a bit of a general one, to make people aware of the fact that we want to support jsr223 more and everyone is invited to help with ideas, suggestions and concrete implementations.
And for getting a good base experienced jsr users are needed. :slight_smile:

I’m starting to develop my first Jython automation rules and use VSCode for editing and linting.
After configuring VSC according to the instructions mentioned in post#1 and post#8, I still get some errors on a very simple rule I ‘stole’ from Rich :smiley:, just to see if it all works.

from core.rules import rule
from core.triggers import when

@rule("Reset Expire Binding Timers", description="Sends an ON command to all members of gResetExpire if they were restoreOnStartup to ON", tags=["admin"])
@when("System started")
def reset_expire(event):
    reset_expire.log.info("Restarting Expire binding Timers")
    for timer in ir.getItem("gResetExpire").members:
        events.sendCommand(timer, ON)

produces these errors:


The rule works fine, but this way it will be difficult to distinguish the ‘real’ errors in my scripts. If I understand post#6 from @CrazyIvan359 correctly, we’ll have to live with it (for now)?

You got it all!

Those names are injected into the global namespace for the module (file) by the scripting engine in openHAB. If you really don’t want to see them you can go line by line and add # pylint: disable=undefined-variable to the end of the line to have pylint ignore it. See http://pylint.pycqa.org/en/latest/faq.html#message-control for details on that. You could do this for the entire file, but I don’t recommend it, as you will cover up all undefined variable errors.

Not really an attractive option. I guess, I’ll live with it. :sunglasses:

The example I provided resolves this. Getting rid of these false errors is worth it IMO, but I don’t often mistype variable names. :slightly_smiling_face:

That’s what I expected, but even after a VSC restart, it still complains about undefined variables.

I’d forgotten about that! Did you end up putting this in the docs?

Not yet… still backlogged

This works for me… with the .pylintrc at the root of OPENHAB_CONF, which is where my workspace lives. I am also using the SSH extension. Are the other things being ignored too, or is it just the undefned-variable? Which linter are you using? You might want to try generating the pylintrc file and see if that helps.

Just set it up in mine, working fine.

I notice that the defaults from VSC are ignored and only the settings from the RC file are used when linting. While this makes sense for the repo where we want all the conventions and such to be followed, I don’t think it makes sense for users’ ohconf dirs. I’ll chuck in a PR for adding the file to repo and I’m going to make a modified version that resembles the VSC defaults and add that to the docs. We can discuss more in the PRs.

What defaults from VSC?

Don’t bother… I have it in queue to commit since 11/6!