Bug 391508 - Kritarunner -s expects known module, not filepath
Summary: Kritarunner -s expects known module, not filepath
Status: CONFIRMED
Alias: None
Product: krita
Classification: Applications
Component: Scripting (show other bugs)
Version: 4.0 pre-alpha
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2018-03-07 09:51 UTC by Fredrik Averpil
Modified: 2021-08-16 09:25 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Fredrik Averpil 2018-03-07 09:51:11 UTC
kritarunner.exe --help says:

-s, --script <script>  The Script to run. Do not append the .py
-f, --function <function>  The function to call (by default __main__ is called)

But kritarunner actually expects the --script parameter to pass on a Python module name, and this module must exist in one of the internal search paths which kritarunner uses (details further below).


-- PROPOSAL --

Preferably, make kritarunner accept a simple script filepath. As an alternative, make it possible to specify on which path the Python module should be searched for.


-- BACKGROUND --

I had trouble getting this to work on my Windows box:
"C:\Program Files\Krita (x64)\bin\kritarunner.exe" -s  C:\Users\fredrik\Desktop\kritadev\kritacomp -f make_layered_psd_from_images()

After getting some IRC help from boud, I checked the output of DebugView, which gave me this clue:
[13956] krita.scripting: "ModuleNotFoundError: No module named 'C:\\\\Users\\\\fredrik\\\\Desktop\\\\kritadev\\\\kritacomp'"

So, it turns out that what the -s parameter wants is actually a module name, not a filepath. I tried to CWD into my directory and tried again:

cd C:\Users\fredrik\Desktop\kritadev
"C:\Program Files\Krita (x64)\bin\kritarunner.exe" -s kritacomp -f make_layered_psd_from_images()

This time around, I got this:
[19224] krita.scripting: "ModuleNotFoundError: No module named 'kritacomp'"

Okay, that's fine. I need to make sure the script is on my PYTHONPATH, I guess. So I made sure to have the "kritadev" folder on my PYTHONPATH and I tried again:
set PYTHONPATH=C:\Users\fredrik\Desktop\kritadev
"C:\Program Files\Krita (x64)\bin\kritarunner.exe" -s kritacomp -f make_layered_psd_from_images()

But I still received the same ModuleNotFoundError. Judging from the DebugView output, it has successfully registered my PYTHONPATH, but it doesn't add it to its own search locations:
[19224]  Python path: "C:\\Users\\fredrik\\Desktop\\kritadev"
[19224] Setting python paths: "C:/Users/fredrik/AppData/Roaming/kritarunner\\;C:/Program Files/Krita (x64)/bin\\;C:/Users/fredrik/AppData/Roaming/kritarunner/pykrita\\;C:/Program Files/Krita (x64)/share/pykrita\\;C:/Program Files/Krita (x64)/share/krita/pykrita\\;C:/Program Files/Krita (x64)/lib/krita-python-libs;C:/Program Files/Krita (x64)/python/python36.zip;C:/Program Files/Krita (x64)/python"

Dropping the "kritacomp.py" script into either of those paths above will suddenly make my command work and the script executes beautifully!

It's just that... I can't have my script manually placed on my local machine. So still can't use kritarunner.

--

So, a couple of ideas (some good, some better):

1 - GOOD:
* Make kritarunner add whatever is on PYTHONPATH to its own search paths, or make it possible to specify a custom search path. Without this, kritarunner can basically never find any module in an arbitrary user-defined location. This is very, very important that kritarunner can support a custom module location in some way.
* Update the kritarunner --help message, to be more clear on that it expects a  module name, not a filename or filepath, and where kritarunner searches for this module.

2 - BETTER:
* Add a new kritarunner parameter which will accept script filepath instead of a module name. I don't have a preference in terms of whether a function needs to be specified in tandem with this argument or not.

Personally, I find dabbling with PYTHONPATH very, very messy. I would strongly encourage you to make kritarunner support a single filepath leading up to a Python script file regardless of how you want to tackle this bug report.
Comment 1 Fredrik Averpil 2018-03-08 11:29:32 UTC
I just had a quick look at the code in plugins/pykrita/kritarunner/plugin/utilities.cpp.

In Python::setPath I can see that PYTHONPATH is not being merged into Krita's search paths on Windows and in some scenarios, it is being skipped on macOS/Linux too...

I'd say either _always_ merge PYTHONPATH into the search paths or _never_ do it. The latter probably being a wise choice avoid future problems (which usually turns up when users start putting stuff in their PYTHONPATH).

Regardless, I want to re-iterate on that I would prefer to specify a script filepath to kritarunner. This would not only add simplicity to kritarunner, but also offer the possibility to tailor to the user's need in terms of the script's location.

After having given all of this some thought, it would also be good to be able to define arguments or the function name to execute (with arguments to the function).
Comment 2 Halla Rempt 2018-03-09 10:55:15 UTC
Git commit 720abdf60609493cf4287fdc2587cc3af09fd5ad by Boudewijn Rempt.
Committed on 09/03/2018 at 10:55.
Pushed by rempt into branch 'master'.

Disable the 3.0 defaults bundle by default

This is an ugly hack, but since we cannot whitelist by-default-blacklisted
default resources, since there's no concept of whitelisting, hacking around
with the config file is the best we can do.

M  +2    -1    krita/data/bundles/CMakeLists.txt
A  +-    --    krita/data/bundles/Krita_3_Default_Resources.bundle
M  +13   -0    libs/widgets/KoResourceServer.h
M  +3    -1    libs/widgets/KoResourceServerProvider.cpp
M  +10   -2    plugins/extensions/resourcemanager/dlg_bundle_manager.cpp

https://commits.kde.org/krita/720abdf60609493cf4287fdc2587cc3af09fd5ad
Comment 3 Halla Rempt 2018-03-09 10:55:27 UTC
Git commit cef00e79ae2d5de02eb47f6523bacb046177efdc by Boudewijn Rempt.
Committed on 09/03/2018 at 10:55.
Pushed by rempt into branch 'krita/4.0'.

Disable the 3.0 defaults bundle by default

This is an ugly hack, but since we cannot whitelist by-default-blacklisted
default resources, since there's no concept of whitelisting, hacking around
with the config file is the best we can do.

M  +2    -1    krita/data/bundles/CMakeLists.txt
A  +-    --    krita/data/bundles/Krita_3_Default_Resources.bundle
M  +13   -0    libs/widgets/KoResourceServer.h
M  +3    -1    libs/widgets/KoResourceServerProvider.cpp
M  +10   -2    plugins/extensions/resourcemanager/dlg_bundle_manager.cpp

https://commits.kde.org/krita/cef00e79ae2d5de02eb47f6523bacb046177efdc
Comment 4 Halla Rempt 2018-03-09 10:56:00 UTC
Er... Wrong commit.
Comment 5 Dhruv Govil 2018-03-24 00:49:17 UTC
I agree with Frederik on his proposed solutions and I share his concern over expecting the module to be importable.

It would be very in line with other packages like Nuke, Katana, Maya etc to allow the running of a script from a full path or relative path.
Comment 6 Julian Steinmann 2018-09-15 14:36:46 UTC
I am not very familiar with the technical details of kritarunner, but this does sound like a solid proposal to me.