[Skencil-devel] Revitalising Skencil

[Igor Novikov]

On Mon, Nov 1, 2010 at 10:18 PM, Bernhard Herzog <bh at intevation.de> wrote:

> On 29.09.2010, Igor Novikov wrote:
> > Distutils build supposes that installed python application/library
> contains
> > one or several
> > python packages.
>
> That could be worked around, if necessary.


I prefer avoiding abundant workarounds because enough of the problems
that already exist in various Linux distributions.


>  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

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


> > 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?


The primary goal is provide a lot of packages for different latest distros.
And these packages
should be really working packages but not a fake without dependencies.


> 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.
>

Extra complex setup.py is great for programmers, not for regular users.
There is no difference in runtime where application is installed. But
Thuban compilation is a rocket science for conventional user.  Whereas
Skencil 1.0alpha package can be built by simple command:

python setup.py bdist_rpm

or for Debian distros:

python setup.py bdist_deb

Any user prefers installing package but Thuban setup.py doesn't provide
such possibility. So people need waiting for application update in
repository.
Sometime it takes more than one year. Also you cannot providing ready
packages for latest release because such task takes a lot of time.


>
> 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?
>

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

I think it's not a good idea reproducing this issue in Skencil. Root package
should not
contain a heavyweight initialization. Currently Sketch package serves as a
global reference
for different components. This is really bad pattern like global variables
in Basic/PHP

So my personal opinion is:

1.Don't change project structure for 1.0 (Tk version). 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 and Lib/ package is
removed.
   But as a result we have simple and efficient package build. I think
revitalizing
   milestone is not for deep project refactoring.

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


-- 
Regards,

Igor Novikov
sK1 Project
http://sk1project.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wald.intevation.org/pipermail/skencil-devel/attachments/20101102/2e4d4da4/attachment.html