[Skencil-devel] Revitalising Skencil

Bernhard Herzog bh at intevation.de
Mon Nov 1 21:18:18 CET 2010


On 29.09.2010, Igor Novikov wrote:
> On Mon, Sep 27, 2010 at 1:36 PM, Bernhard Herzog <bh at intevation.de> wrote:
> > The way it has been implemented will likely lead to subtle bugs or
> > strange exceptions later on.  You can now import the Skencil modules
> > using two different absolute module names.  E.g.
> > skencil.Sketch.UI.mainwindow and Sketch.UI.mainwindow will now be
> > different modules imported from the same python file.  If both names are
> > used in the same problem it's likely to cause
> > problems.
>
> Distutils build supposes that installed python application/library contains
> one or several
> python packages.

That could be worked around, if necessary.  One general problem applications 
like Skencil have with distutils is that distutils is meant for libraries, 
not applications.

> Skencil structure has following folders: 
>
> Lib
> Plugins
> Resources
> Script
> Sketch
>
> I think it's not a good idea to introduce such python packages due to
> possible clashes.

That just means they can't be put directly under e.g. site-packages.

> Therefore internal Skencil structure was wrapped as a single package with
> unique 'skencil' name.

It doesn't have to be a package. That's what I'm concerned about and it's what 
I think is wrong, currently.  What exactly is your goal?  If the goal is to 
make it possible for someone to install Skencil and then to be able to write 
python code that can import Skencil modules without any additional PYTHONPATH 
or sys.path modifications, that could have been achieved without an 
additional package.  It would have sufficed to put a single python module, 
called e.g. skencil.py, into site-packages that when imported adds the actual 
installation directory of Skencil to sys.path.  Where Skencil is actually 
installed doesn't really matter in that case.  It could still be in a 
sub-directory of site-packages if that's not a python package.

That's an approach we used in Thuban.  Its setup.py creates a file 
thubaninit.py in site-packages with basically just the following content:

sys.path.insert(0, %(thubandir)s)


Where %(thubandir)s is replaced with the actual installation directory.
See e.g. 
https://wald.intevation.org/plugins/scmsvn/viewcvs.php/trunk/thuban/setup.py?rev=2889&root=thuban&view=markup
for how that's put into setup.py.

I think the extra skencil package should be removed again before the final 
release.

> Of course all these folders could be moved inside Sketch package but this
> will lead to serious
> project refactoring. Also when you import Sketch package __init__.py runs a
> lot of initializing code
> including some tricks like creating runtime packages. Such behavior breaks
> a work of some
> python applications.

In what way to they break?

  Bernhard


More information about the Skencil-devel mailing list