[Skencil-devel] Revitalising Skencil

[Bernhard Herzog]

On 02.11.2010, Igor Novikov wrote:
> On Mon, Nov 1, 2010 at 10:18 PM, Bernhard Herzog <bh at intevation.de> wrote:
> >  One general problem applications
> > like Skencil have with distutils is that distutils is meant for
> > libraries, not applications.
>
> It seems this conclusion is not correct. Distutils is meant for module
> distribution, not libraries only.
>
> http://docs.python.org/distutils/introduction.html

As that page explains in section "1.3. General Python terminology":

   module
      the basic unit of code reusability in Python: a block of code imported
      by some other code. Three types of modules concern us here: pure Python
      modules, extension modules, and packages.

So, a module in the sense used in distutils and in Python in general, btw, is 
a library, not an application or a script.

> There is a lot of python end user application which use distutils without
> workarounds, just for conventional install.

Which ones?  I'm not saying distutils cannot be used for applications.  We did 
that for Thuban, and even Skencil 0.7 has a distutils based setup.py.  
distutils is mainly intended for Python modules, though, and can get in the 
way a little when trying to package an application.  Things may have 
improved, though, since I last used distutils seriously for application 
distribution.

> > > 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?
>
> Initially UniConvertor had a structure as you proposed, i.e. root package
> __init__.py was similar to Sketch __init__.py But after RH bugreport we have
> fixed this issue:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=484301

That issue seems to have nothing to do with how the packages are organized, or 
import tricks, or any other code that tries to be too clever for its own 
good.  In uniconverter 1.1.3, importing the uniconverter package simply has 
the side-effect of trying to parse command line arguments and exiting the 
interpreter if there are problems with those arguments.  That's not something 
a library should do.  Sketch 0.6 does not share that problem, AFAICT.

> So my personal opinion is:
>
> 1.Don't change project structure for 1.0 (Tk version).

Exactly!

> Actually it's almost the same
>    Skencil 0.6.17 structure. Take a look on following illustration:
>
> http://saveimg.ru/pictures/02-11-10/6facaf814684b114a74fb3b84a9e94f2.png
>
>    Only startup script is replaced by __init__.py

There's a crucial difference.  You introduced a new Pythong package above the 
existing Sketch package and do some sys.path manipulation during import that 
makes it possible to import the Skencil modules under their 'old' names.  
That means they can be imported with two different absolute names.  That *is* 
wrong.  Two different absolute names for the same python file is one of the 
main causes for problems people have with imports in Python.

Note that I only object to the top-level directory being a Python package.  
Rearranging the code in the repository is not the problem, even though I'm 
still not convinced it was necessary.  But if it helps you create binary 
packages for the various linux distributions, that's OK.

> 2.Developing next Gtk version resolve this issue removing all tricks from
> application start (runtime Base package, Sketch package as a global
> reference etc.) 

We should discuss this in detail before any work is done in that regard.

It may not be obvious from my postings, :-), but I appreciate the work you put 
into revitalising Skencil.  Thanks for the work so far.

  Bernhard