[Thuban-list] Started GD based renderer, suggestions

[Andreas Rottmann]

Bernhard Herzog <bh at intevation.de> writes:

>> However, I will use the renderer (and non-UI parts of thuban) from a
>> CGI application, so I have some suggestions for making re-use of the
>> thuban code easier for other applications.
>> 
>> 1) Install the Thuban as a regular Python package (i.e. move
>>    $libdir/thuban/Thuban to $libdir/python2.X/Thuban. 
>
> I think you mean $libdir/python2.X/site-packages/Thuban.
>
Yes, that's what I meant.

> I'm not sure I actually want to put Thuban in site-packages. Thuban
> currently evolves quite rapidly and I expect the interfaces to change a
> lot, so applications that use thuban are better off to include a copy
> with the application. 
>
Yes, you're quite right here, but there are no applications using
Thuban yet, and I guess it would be reasonably to expect applications
that want to build on it by now (such as my CGI stuff) to follow API
changes across releases.

> Putting thuban into site-packages won't work very
> well once you have several applications requiring different Thuban
> versions.
>  
Sure, but I hope that doesn't really happen (see above).

>>    This will fix the 'feature' of the current CVS-based installation
>>    of the thuban executable only being startable from $libdir/thuban
>>    (so that the Thuban package is in the python path, which includes
>>    the current dir by default).
>
> Actually, python puts the directory containing the "script", that is the
> optional filename argument to the interpreter, into sys.path or the
> empty string if no filename was given. E.g. when starting Python as
>
> python /usr/local/lib/thuban/thuban.py
>
> sys.path[0] will be "/usr/local/lib/thuban/"
>
> Furthermore, if the script name is a symlink, the directory will be the
> directory containing the file the symlink points to, so you can simply
> put a symlink to thuban.py into, say, /usr/local/bin and python will put
> the right directory at the front of sys.path if you call that symlink.
> This is what "setup.py install" does, actually.
>
Well, that doesn't work for me (I use GNU stow):

andy at alice:~% ls -l /usr/local/bin/thuban
lrwxrwxrwx    1 root     staff          25 Apr 28 13:54 /usr/local/bin/thuban -> ../stow/thuban/bin/thuban
andy at alice:~% ls -l /usr/local/stow/thuban/bin/thuban
lrwxrwxrwx    1 root     staff          43 Apr 28 13:54 /usr/local/stow/thuban/bin/thuban -> /usr/local/stow/thuban/lib/thuban/thuban.py
andy at alice:~% /usr/local/bin/thuban
Traceback (most recent call last):
  File "/usr/local/bin/thuban", line 12, in ?
    import Thuban
ImportError: No module named Thuban

Invoking /usr/local/stow/thuban/bin/thuban directly works, though. It
seems Python is not clever enough to follow more than one symlink.

>> 2) I quite don't like the fiddling of sys.path to have the Lib
>>    directory included. Why not simply explicitly reference Lib, or
>>    move its contents to the Thuban package?
>
> The modules in Lib used to be very independend of Thuban, especially at
> the beginning. The situatuion has changed a bit since then, and
> especially the wxproj obviously is very Thuban specific. The shapelib
> bindings are also a bit Thuban specific in that the shapelib version
> they use has been slightly modified.
>
I already heard that about shapelib... Wouldn't it be good to push
these changes upstream and use an out-of-the-box shapelib?

> So it might be indeed better to organize them a bit differently. I'm a
> bit undecided about this, but wxproj should probably be moved to
> Thuban/UI and the shapelib and proj bindings to Thuban/Lib.
>  
So the GDRenderer would also go under Lib/?

>> 3) Split the Thuban build into the non-UI part, which is quite generic
>>    (i.e. doesn't need wxWin/wxPython) and the UI part. This will make
>>    it possible, for instance, to build/install a bunch of utilities that
>>    convert .thuban files to PNG or whatsoever without having the wx stuff
>>    installed for building.
>
> This seems indeed useful.
>
>> I volunteer to write patches to solve the above (perceived) issues
>
> Great!
>
> Patches for 2) and 3) (preferably separate patches for each) should only
> affect setup.py, I think.
>
Well, I don't know what the proper solution for (2) is, but I'd
suggest to dump that sys.path magic and use Lib explicitly.

>> case someone is interested, the preliminary GD renderer is attached.
>
> Your GDRenderer class shares a lot of code with MapRenderer which
> obviously suggests that it would be good to separate the common
> rendering logic from the GD/wxDC specific bits so that they can be
> derived from a common base class. 
>
Indeed, I already tought about that too.

> Patches for that would also be welcome. However, the render is likely to
> be changed in some respects when the PostGIS support will be added, so
> perhaps this kind of refactoring should wait until after that (I can't
> give any time-frame for that currently, though).
>
OK.

Regards, Andy
-- 
Andreas Rottmann         | Rotty at ICQ      | 118634484 at ICQ | a.rottmann at gmx.at
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Packages should build-depend on what they should build-depend.