PythonRunnerPr: add if avoiding using a local directory is essential

[johann-petrak]

There was a discussion in issue #18 that also mentioned that in an embedded scenario there may be issues with write access.
The PythonPr currently uses the gatenlp package directly from the JAR, but even if the script is also in the jar, it always gets copied into the working directory before its is run.
This is necessary, because the PR also allows to update the script and for that it must be stored locally.

The way how things are implemented, it would be possible to also run a script directly from the JAR by loading the script as a module.

If this is really required, the best way to support it would be to have another Pr, e.g. PythonRunnerPr which does not allow editing and simply takes the URL of the script to run.
If we do not allow editing in that PR, we can also make the script URL parameter a runtime parameter, so in the gui, we can change the URL of the program to run for an existing PR.

[drj11]

Can we disable the editor if we can't edit the Python script? (for example, if it's inside a JAR).

I don't really like the idea of having two plugins.

[johann-petrak]

Currently, if a file is read-only, it gets automatically copied into the working directory and used from there. This therefore works not only for files from the JAR, but also arbitrary URLs, e.g. for a file on a web server.
I kind of like this, but I can also see that it does add complexity.

The VR cannot be disabled, because that is a compile time property, however we could make the VR behave differently, e.g. just show a message or a read only view without buttons.
If we change things like that, I think we could completely get rid of the workingDirUrl and pythonProgramPath parameters.

We would lose the following: a) being able to specify arbitrary read-only URL, b) specify python files relative to a working directory URL.

[greenwoodma]

I think you can have the setTarget (I think that's the right name) method of a VR respond in such a way that it won't display based on the specific instance of the PR. You could test the URL to check it's a file and then only display the VR in that case. Would be simpler than coding the VR to turn off the buttons etc.

[johann-petrak]

OK, would be happy for people to share their opinion if changing the plugin is what is wanted: rather than on-the fly copying to the working directory and supporting any URL, the PR would:

• support file: URLs and allow to edit them
• support to run jar URLs but not allow to edit them (but the script can always be copied to disk with the extract utility, I think)
• refuse to support any other URLs for the python script

@drj11 @greenwoodma @ianroberts @deansong what would you prefer?

[greenwoodma]

My view is that any files that are part of the plugin should be run from within the JAR where possible and hence not be editable. If a user wants to edit the resource then they have to export it via the plugin manager and then create a new PR instance pointing at the file under their control. At that point the resource will be a file and so the editor will then work.

Having said all that, are we talking about the python code that is essentially part of the plugin, rather than the users actual python code? If so then we don't really want to encourage people editing the code, because of the reproducability angle. Essentially if the code is part of the PR (rather than a resource like a gaz list or a jape grammar) then it shouldn't be easily editable; while it might be easy to edit the python it would be akin to editing the java code of the PR which isn't something we would encourage or make easy for normal users.

[drj11]

I have a side question about URLs in Java land. Is it possible to use a URL to refer to a file inside a JAR?

It wasn't clear to me that it was possible to specify a completely general URL for the python script. That's quite a fun feature, but I'm not sure how useful it is in practice. OTOH, if it comes "for free", then that's okay.

I agree with @johann-petrak 's proposal:

I think we want to support:

• running Python code that is editable on disk (for development)
• running Python code that is in a JAR and essentially uneditable (for reproducibility)

[greenwoodma]

Yes, you can have a URL pointing at a file in a jar. It's essentially jar:<url to jar file>!<path to file in jar>

It gets a bit more complex in GATE as we also have the ResourceReference class that allows for what are essentially URLs that reference files inside a GATE plugin. These look like creole:<group>;<artifact>;<version>/<path in plugin to resource>

[greenwoodma]

and yes I agree with the two things we want to support. I think what we don't want is the PR to always copy the file to a directory so it can be edited. That should be a user task (if applicable) with the export resources option in the plugin manager.

[johann-petrak]

Here we are talking only about the actual code the user wants to run, not the gatenlp package, which is always used from the JAR by default.
My only concern is that extracting the resources is not easy to discover and (I think) it is not possible to just extract one single pipeline or resource subdirectory only all of the resources (which in case of the python plugin would also include the gatenlp package), but I guess we can add a description to the documentation about this.

I tend towards changing the plugin so that we get rid of that automatic copying thing and try to use the JAR files in place with the VR disabled.

[greenwoodma]

So if this is just python code from the user, how does it even end up inside the plugin?

[johann-petrak]

It is code the user wants to run but not from the user, the code in the JAR is code that is part of the prepared pipelines.
Of course it could also be code from some other plugin that includes python code for the plugin or some other situation of running GATE embedded with the python plugin from a JAR only.

[greenwoodma]

so the analogy would be something like the GATE pipelines that are packaged in JARs? in that case yes, just run them from within the JAR. If the user wants to modify them then they need to extract them in the same was as any other resource.

[johann-petrak]

Yes, agree, is already on my todo list: #34 :D