How to specify which live error profile to use for a python project?

[rowbearto]

I have a wrapper script (bash) around pylint3 that sets environment variables (like PYTHONPATH) before running python3.

I added this script to python "live error profiles".

How do I tell SE to use this specific live error profile for an individual project?

At the moment I don't see any live error profile running and there are 2 python3 ones found and installed in the "live error profiles" screen. How to get the live error profile (and a specific one) to run for my project?

[patrick]

You should just be able to select the profile you added in the "Default profile" pulldown.  The "<Auto>" setting just tries to pick between Pylint and Pylint3 based on the python version.  It won't pick a user created profile.

[rowbearto]

OK. I have my user created profile in the "Default" and have "enabled" clicked for it, but it doesn't seem to be running?

I know the error parsing is properly setup because when I run this pylint3 wrapper as a "build" I can go to next/previous error.

Is there a way to see the console output of the live error python3 as well as listing its contents in the "Message List" tab?

[rowbearto]

Also it would be nice if I could set this on a project by project basis instead of globally. For other projects I may want to use other wrapper scripts around pylint3.

[patrick]

It will get that.  Not in the next beta (2), but sometime after.  It currently checks for live profile overrides in the project file now, but there's no UI yet to set it up. 

[rowbearto]

Thanks. Still I don't see my user one running even though I set it as the "Default" and clicked "Enabled" for it.

[patrick]

There is a bug in beta 1 where live errors can stop working for a project.  Sometimes closing and re-opening the project can make it work again, but I think the only sure fire workaround is to restart.  If that doesn't do anything, check to see if there's anything in CONFIG_DIR/25.0.0/rte/rteout.   It's possible that file can contain an error that won't show up if the error message list because it doesn't match any of the error regular expressions in the error parsing setup. 

[rowbearto]

I see what the problem is. My wrapper script is taking the full path of my source file and finding a root path in it which it uses as a base directory for setting PYTHONPATH.

However the SE is copying my source file under CONFIG/25.0.0/rte subdirectory which causes the file passed to pylint to have a different full path which does not contain the base directory I'm searching for. So then my wrapper script just complains that the source file is not under my base directory.

Don't know a good way to solve this, need to think about it. I don't want to explicitly set PYTHONPATH anywhere because it will change depending on where I clone my repository.

[rowbearto]

I understand why SlickEdit needs to make a copy, as I could be editing the file.

If there was some way that SlickEdit could tell my script the original path of the file?

But I also see problems for when a .py file does an "import" for other files in the same directory. Copying the file like this without copying the other files to "import" will also cause a failure. Don't know the solution, need to think about it.

[patrick]

I ran into the same thing yesterday with another language where the relative imports are based off the path of the file given to it. 

For cases where you can give the checker import paths on the command line, I can supply some more % escapes we can use in the command line that expand to the original file path, and the original file's directory. 

I was also considering an option to make the temp file in the same directory as the source file, since it has a short life.  But that wouldn't be usable in all situations - some languages base an implicit module name from the filename which could occasionally get you in trouble, and I think there are some source control systems that provide virtual mounts where unexpected temp files could be a problem.  But it might be worth it to provide the option.  I haven't decided yet.
 

[rowbearto]

Being able to get the original file directory and path with % escapes will be very useful.

Putting the temp file into the same directory is something to consider, but it also has pitfalls as you mentioned. This needs to be considered carefully. At least with python could use the % escapes with a wrapper script to put the original path into the PYTHONPATH and this would probably work, but needs more investigation and thought.

[jporkkahtc]

WRT Making a copy of the source file:
I tried this manually, and I found that if I add the original directory to PYTHONPATH, then the import statements in the copied source file are able to find files from the original directory.

[patrick]

For beta 3, the original source path and directory will be available through %of and %od escapes.  You'll also be able to set environment variables in the profiles.  (ie, "PYTHONPATH=%rw/src:%rw/some_other_dir:%(PYTHONPATH)")

[rowbearto]

Excellent! Thanks Patrick.

Can these escapes also be made available in build tools? For example I want to set PYTHONPATH for execute and debug of a python script, these escapes would be helpful.

Additionally for execute and debug I want the same python path, but I need to set it 2x, once for each tool (debug and escape).

I'm also interested in running a script that sets PYTHONPATH as this is what I do normally. If there is any way to source a script like this before live errors, execute or debug that could be useful.

[rowbearto]

Another thought.

In some of my python scripts, at the start of the script I get the directory of the running script:

Code: [Select]

(dirName, fileNameWithExt) = os.path.split(__file__)
and use a path relative to dirName for setting PYTHONPATH:

Code: [Select]

sys.path.append(f"{dirName}/../../lib")
But if the script is copied for pylint, that won't work.

I'd rather not have to modify the python script to take a command line argument with the original dir.

So perhaps SE could also set an environment variable before running the script with the original full path to the file?

Then I can check for the existence of that environment variable and use it before looking at __file__.