From kwrite-devel Tue Nov 12 17:50:21 2013 From: Alex Turbov Date: Tue, 12 Nov 2013 17:50:21 +0000 To: kwrite-devel Subject: Re: Python plugins refactored, step 2 Message-Id: X-MARC-Message: https://marc.info/?l=kwrite-devel&m=138427863220721 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============4787388577022178145==" --===============4787388577022178145== Content-Type: multipart/alternative; boundary=f46d041038a7843e5904eafe7b05 --f46d041038a7843e5904eafe7b05 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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. wrote: > hi, i already mentioned it in a review request, but i think this is bette= r. > > how about making python plugins python modules? > > currently, they are =93either a single-file module or a directory full of > modules, with one special module that gets imported/executed=94, which is= not > only more unwieldy to explain, but also a more complex implementation and > puts many modules into the namespace. > > e.g. i=92m not sure if it=92s possible to create a =93util.py=94 module i= nside 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=92ll 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=E2t=E9 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 =93...plugins/bar/=94= and > =93...plugins/=94 (in that order) > > now the base name (remove directory part and =93.py=94 extension) of both= gets > imported: > > 1. `py.import("foo")`: python checks in =93...plugins/bar/=94, doesn=92t = find > it, checks in =93...plugins/=94, finds & imports it > 2. `py.import("bar")`: checks in =93...plugins/bar/=94, finds & imports i= t > 3. during importing, =93bar/bar.py=94 checks for the =93baz=94 module in > =93...plugins/bar/=94, finds & imports it > > now if any plugin directory that gets prepended after =93bar/=94 would co= ntain > baz.py, or if any plugin depended on some system module called =93baz=94,= we=92d > be fucked. > > --- > > my proposed changes: > > * don=92t change the path after adding the plugin directories (in our > example, just add =93...plugins/=94, and be done with it) > * just put the module name in the .desktop files (in our example: =93foo= =94 > and =93bar=94) > * 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 =93...plugins/=94 gets prepended to the python = path > > the names given in the desktop files of each activated plugin =96 =93foo= =94 and > =93bar=94 =96 get imported: > > 1. `py.import("foo")`: python checks in =93...plugins/=94, finds & import= s it > 2. `py.import("bar")`: python checks in =93...plugins/=94, finds & import= s it > (as directory-based module) > 3. during importing, =93bar/__init__.py=94 checks for the =93.baz=94 modu= le 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 > > --f46d041038a7843e5904eafe7b05 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
sounds reasonable. easy to fix.
the only question:= what X-KDE-Library of the bar/bar.desktop should contain?
<= div class=3D"gmail_extra">

On Tue, Nov 12= , 2013 at 9:33 PM, Philipp A. <flying-sheep@web.de> wrote:=
hi, i already men= tioned it in a review request, but i think this is better.

how about= making python plugins python modules?

currently, they are =93either a single-file module or a directory full = of modules, with one special module that gets imported/executed=94, which i= s not only more unwieldy to explain, but also a more complex implementation= and puts many modules into the namespace.

e.g. i=92m not sure if it=92s possible to create a =93util.py=94 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=92ll 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= =E2t=E9 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 =93...plugins/bar/=94 a= nd =93...plugins/=94 (in that order)

now the base name (remove directory part and =93.py=94 extension) of bo= th gets imported:

1. `py.import("foo")`: python checks in = =93...plugins/bar/=94, doesn=92t find it, checks in =93...plugins/=94, find= s & imports it
2. `py.import("bar")`: checks in =93...plugins/bar/=94, finds &am= p; imports it
3. during importing, =93bar/bar.py=94 checks fo= r the =93baz=94 module in =93...plugins/bar/=94, finds & imports it

now if any plugin directory that gets prepended after =93bar/=94 would cont= ain baz.py, or if any plugin depended on some system module called =93baz= =94, we=92d be fucked.

---

my proposed changes:

* don=92t change the path after = adding the plugin directories (in our example, just add =93...plugins/=94, = and be done with it)
* just put the module name in the .desktop files (i= n our example: =93foo=94 and =93bar=94)
* 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
fo= o.desktop
foo.py
bar/bar.desktop
bar/__init__.py
bar/baz.py
= $ head -n 1 bar/__init__.py
from .baz import symbol=A0 # note the dot ```

how does it work now?

just the plugin director= y =93...plugins/=94 gets prepended to the python path

the= names given in the desktop files of each activated plugin =96 =93foo=94 an= d =93bar=94 =96 get imported:

1. `py.import("foo")`: python checks in =93...plugins/=94, fi= nds & imports it
2. `py.import("bar")`: python checks in = =93...plugins/=94, finds & imports it (as directory-based module)
3.= during importing, =93bar/__init__.py=94 checks for the =93.baz=94 module n= ext to itself (explicit relative import), finds & imports it

baz is invisible for other plugins

---

<= div>what do you say?

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


--f46d041038a7843e5904eafe7b05-- --===============4787388577022178145== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KWrite-Devel mailing list KWrite-Devel@kde.org https://mail.kde.org/mailman/listinfo/kwrite-devel --===============4787388577022178145==--