Puppy and Python - do they get along?

[TJK]

I've been using Puppy Linux for years now. I think it's the best Linux for my needs and it's very stable. BUT there is one thing that continues to bug me (and I don't recall these issues with KDE and Gnome), some modules seem to not work in Puppy. I realize that I don't know much about Python, and that may be the main problems, but it would be nice if there was someone who would work with me when I'm having issues (someone who knows Python). Ideally I'd like to see a "Python in Puppy" thread, because there must be others like me who are having problems.

Let me give you an example of my latest issue:
I have tried several ways of installing GRAMPS... and in the past I've had situations where it wouldn't load. But most recently I cannot find a way for GRAMPS to use the modules: pyexiv2, osmgpsmap, and pyspell. This is the terminal message that I get:

2473: WARNING: Spell.py: line 60: Spelling checker is not installed
5657: WARNING: geography.gpr.py: line 42: WARNING: osmgpsmap module not loaded. Geography functionality will not be available.
5830: WARNING: bottombar.gpr.py: line 90: WARNING: pyexiv2 module not loaded. Image metadata functionality will not be available.

All of these modules have been installed using the Puppy Package Manager, so what's the problem? It'd be nice if these modules were automatically recognized...

[tallboy]

Hi TJK.
I run Gramps, and have done so for a long time, with several versions, first in Debian, later in puppy. The missing functions you describe, have only appeared in the latest Gramps. The same with Graphviz: I don't know if you ever tried to use one of the: 'Gramps menu -> Reports -> Graphs' functions. I have never been able to get a result from those graphs, even with all deps installed, so lately I simply skip installing them. The fact that the libs are not there, only block you from using these specific functions, they don't make Gramps run different in any other way.

I made a desktop icon to start Gramps, so I don't have those pesky terminal messages haunting me no more!

I have run Gramps in dpup_484beta4, dpup_485, lupu_5.2.5 and 5.2.8. I have tried it in Slacko, wary, wheezy and lots of other puppys, and Gramps work - like all earlier versions, absolutely perfect! The missing functions are coupling of maps to gps ccordinates and such fancy, new things, they are probably not the first functions you'll miss, even if they may be useful. Personally, I have more than enough work with loading new people data into Gramps, so there are many functions I haven't had the opportunity to test, yet.

There is a beta version of the new 4.0 available, but I haven't read up on the dependencies for that version yet, maybe an upgraded python will be necessary.

Which puppy are you using? Do you run a full or frugal install, or a live version like me? I save the dot.gramps to a portable USB HD, or to a new session in a multisesson DVD, and later sync it with the HD.

tallboy

[TJK]

I'm still trying to determine why I seem to be getting so many python errors when running Python apps... Here's the latest:

I'm getting PyUnicode errors (see the bottom of page: http://docs.python.org/2/faq/extending# ... nicodeucs2), and I've been told that some of the modules have been compiled with 4-byte Unicode when I am using a 2-byte Unicode python system. I don't completely understand this, but it appears that Puppy allows me to import both unicodes.

I've also started running Lubuntu again and I can load all the Python modules that I want, and run the same Python apps that I do in Puppy, but I never get errors like this... so is this something specific to Puppy? And can this be avoided? Ideally I'd like Puppy to differentiate between these conflicting modules. Or am I way off in this subject...

[tallboy]

Apart from Gramps, and maybe some other built-in programs in puppy, I have tried to avoid applications/programs built in python or other interpreted languages. By interpreted languages I mean languages used for applications/programs that are not compiled to run as an independent unit, but has to start and run in the language used to build them. My reasons: they are usually slower, and often have some of the problems you describe; backward compability is not always good.

I am sorry that I cannot be of help when it comes to python.

tallboy