[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwrite-devel
Subject:    Re: Python plugins refactored, step 2
From:       "Philipp A." <flying-sheep () web ! de>
Date:       2013-11-12 18:05:49
Message-ID: CAN8d9gm7+H6FAeSBR2RTEvKkLvH7i-UtcYQ784LMWAoH-r_p1Q () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


just the module name, which is then directly used by "py.moduleImport()"

bar/bar.desktop contains X-KDE-Library=bar
and
foo.desktop contains X-KDE-Library=foo

or is it a problem if they don't point to physical files?

PS: as long as we still support python 2, we also need to add to all files
inside modules which import sth.: from __future__ import absolute_import


2013/11/12 Alex Turbov <i.zaufi@gmail.com>

> sounds reasonable. easy to fix.
> the only question: what X-KDE-Library of the bar/bar.desktop should
> contain?
>
>
> On Tue, Nov 12, 2013 at 9:33 PM, Philipp A. <flying-sheep@web.de> wrote:
>
>> hi, i already mentioned it in a review request, but i think this is
>> better.
>>
>> how about making python plugins python modules?
>>
>> currently, they are "either a single-file module or a directory full of
>> modules, with one special module that gets imported/executed", which is not
>> only more unwieldy to explain, but also a more complex implementation and
>> puts many modules into the namespace.
>>
>> e.g. i'm not sure if it's possible to create a "util.py" module inside
>> one of your plugins, because another one might have the same. they have to
>> be prefixed, which is rather silly in a namespace-focused language.
>>
>> so i'll explain how it works now:
>>
>> ```
>> $ pwd
>> ...plugins
>> $ ls
>> foo.desktop
>> foo.py
>> bar/bar.desktop
>> bar/bar.py
>> bar/baz.py
>> $ head -n 1 bar/bar.py
>> from baz import symbol
>> ```
>>
>> the desktop files point to foo.py and bar/bar.py
>>
>> Pâté loads both and checks if they are activated. for each activated one
>> that is in a subdirectory, it prepends that one to the python path.
>>
>> if both are activated, the python path now contains "...plugins/bar/" and
>> "...plugins/" (in that order)
>>
>> now the base name (remove directory part and ".py" extension) of both
>> gets imported:
>>
>> 1. `py.import("foo")`: python checks in "...plugins/bar/", doesn't find
>> it, checks in "...plugins/", finds & imports it
>> 2. `py.import("bar")`: checks in "...plugins/bar/", finds & imports it
>> 3. during importing, "bar/bar.py" checks for the "baz" module in
>> "...plugins/bar/", finds & imports it
>>
>> now if any plugin directory that gets prepended after "bar/" would
>> contain baz.py, or if any plugin depended on some system module called
>> "baz", we'd be fucked.
>>
>> ---
>>
>> my proposed changes:
>>
>> * don't change the path after adding the plugin directories (in our
>> example, just add "...plugins/", and be done with it)
>> * just put the module name in the .desktop files (in our example: "foo"
>> and "bar")
>> * change the name of the to-be-loaded submodule inside a plugin directory
>> (bar/bar.py) to __init__.py
>> * change all relative imports inside plugins to python-3-style `from
>> .relative_module import symbol`
>>
>>  now we have
>>
>> ```
>> $ pwd
>> ...plugins
>> $ ls
>> foo.desktop
>> foo.py
>> bar/bar.desktop
>> bar/__init__.py
>> bar/baz.py
>> $ head -n 1 bar/__init__.py
>> from .baz import symbol  # note the dot
>> ```
>>
>> how does it work now?
>>
>> just the plugin directory "...plugins/" gets prepended to the python path
>>
>> the names given in the desktop files of each activated plugin – "foo" and
>> "bar" – get imported:
>>
>> 1. `py.import("foo")`: python checks in "...plugins/", finds & imports it
>> 2. `py.import("bar")`: python checks in "...plugins/", finds & imports it
>> (as directory-based module)
>> 3. during importing, "bar/__init__.py" checks for the ".baz" module next
>> to itself (explicit relative import), finds & imports it
>>
>> baz is invisible for other plugins
>>
>> ---
>>
>> what do you say?
>>
>> _______________________________________________
>> KWrite-Devel mailing list
>> KWrite-Devel@kde.org
>> https://mail.kde.org/mailman/listinfo/kwrite-devel
>>
>>
>
> _______________________________________________
> KWrite-Devel mailing list
> KWrite-Devel@kde.org
> https://mail.kde.org/mailman/listinfo/kwrite-devel
>
>

[Attachment #5 (text/html)]

<div dir="ltr"><div><div><div><div><div>just the module name, which is then directly \
used by "py.moduleImport()"<br><br></div>bar/bar.desktop contains \
X-KDE-Library=bar<br></div>and<br></div>foo.desktop contains X-KDE-Library=foo<br> \
<br></div>or is it a problem if they don't point to physical files?<br><br></div>PS: \
as long as we still support python 2, we also need to add to all files inside modules \
which import sth.: from __future__ import absolute_import</div> <div \
class="gmail_extra"><br><br><div class="gmail_quote">2013/11/12 Alex Turbov <span \
dir="ltr">&lt;<a href="mailto:i.zaufi@gmail.com" \
target="_blank">i.zaufi@gmail.com</a>&gt;</span><br><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div \
dir="ltr"><div>sounds reasonable. easy to fix.<br>the only question: what \
X-KDE-Library of the bar/bar.desktop should contain?<br></div></div><div \
class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5"> On Tue, \
Nov 12, 2013 at 9:33 PM, Philipp A. <span dir="ltr">&lt;<a \
href="mailto:flying-sheep@web.de" target="_blank">flying-sheep@web.de</a>&gt;</span> \
wrote:<br> </div></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div \
dir="ltr"><div><div>hi, i already mentioned it in a review request, but i think this \
is better.<br> <br>how about making python plugins python modules?<br>
<br>currently, they are "either a single-file module or a directory full of modules, \
with one special module that gets imported/executed", which is not only more unwieldy \
to explain, but also a more complex implementation and puts many modules into the \
namespace.<br>


<br>e.g. i'm not sure if it's possible to create a "util.py" module inside one of \
your plugins, because another one might have the same. they have to be prefixed, \
which is rather silly in a namespace-focused language.<br>


<br>so i'll explain how it works now:<br><br>```<br>$ pwd<br>...plugins<br>$ \
ls<br>foo.desktop<br>foo.py<br>bar/bar.desktop<br>bar/bar.py<br>bar/baz.py<br></div>$ \
head -n 1 bar/bar.py<br></div>from baz import symbol<br><div>


<div>```<br><br>the desktop files point to foo.py and bar/bar.py<br><br>Pâté loads \
both and checks if they are activated. for each activated one that is in a \
subdirectory, it prepends that one to the python path.<br><br>

if both are activated, the python path now contains "...plugins/bar/" and \
"...plugins/" (in that order)<br> <br>now the base name (remove directory part and \
".py" extension) of both gets imported:<br><br>1. `py.import(&quot;foo&quot;)`: \
python checks in "...plugins/bar/", doesn't find it, checks in "...plugins/", finds \
&amp; imports it<br>


2. `py.import(&quot;bar&quot;)`: checks in "...plugins/bar/", finds &amp; imports \
it<br></div><div>3. during importing, "bar/bar.py" checks for the "baz" module in \
"...plugins/bar/", finds &amp; imports it</div><div><br>

now if any plugin directory that gets prepended after "bar/" would contain baz.py, or \
if any plugin depended on some system module called "baz", we'd be fucked.<br> \
<br>---<br><br>my proposed changes:<br><br>* don't change the path after adding the \
plugin directories (in our example, just add "...plugins/", and be done with it)<br>* \
just put the module name in the .desktop files (in our example: "foo" and "bar")<br>


* change the name of the to-be-loaded submodule inside a plugin directory \
(bar/bar.py) to __init__.py<br>* change all relative imports inside plugins to \
python-3-style `from .relative_module import symbol`</div><div><br>

</div>
<div>now we have<br></div><div><br>```<br>$ pwd<br>...plugins<br>$ \
ls<br>foo.desktop<br>foo.py<br>bar/bar.desktop<br>bar/__init__.py<br>bar/baz.py<br>$ \
head -n 1 bar/__init__.py<br>from .baz import symbol   # note the dot<br>


```<br><br>how does it work now?<br><br></div><div>just the plugin directory \
"...plugins/" gets prepended to the python path<br><br></div><div>the names given in \
the desktop files of each activated plugin – "foo" and "bar" – get imported:<br>


<br>1. `py.import(&quot;foo&quot;)`: python checks in "...plugins/", finds &amp; \
imports it<br>2. `py.import(&quot;bar&quot;)`: python checks in "...plugins/", finds \
&amp; imports it (as directory-based module)<br>3. during importing, \
"bar/__init__.py" checks for the ".baz" module next to itself (explicit relative \
import), finds &amp; imports it<br>


<br></div><div>baz is invisible for other plugins<br><br>---<br><br></div><div>what \
do you say?<br></div></div></div> \
<br></div></div>_______________________________________________<br> KWrite-Devel \
mailing list<br> <a href="mailto:KWrite-Devel@kde.org" \
target="_blank">KWrite-Devel@kde.org</a><br> <a \
href="https://mail.kde.org/mailman/listinfo/kwrite-devel" \
target="_blank">https://mail.kde.org/mailman/listinfo/kwrite-devel</a><br> \
<br></blockquote></div><br></div> \
<br>_______________________________________________<br> KWrite-Devel mailing list<br>
<a href="mailto:KWrite-Devel@kde.org">KWrite-Devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kwrite-devel" \
target="_blank">https://mail.kde.org/mailman/listinfo/kwrite-devel</a><br> \
<br></blockquote></div><br></div>



_______________________________________________
KWrite-Devel mailing list
KWrite-Devel@kde.org
https://mail.kde.org/mailman/listinfo/kwrite-devel


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic