gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] gnumed not finding local db caused by not using corre


From: Florian Hubold
Subject: Re: [Gnumed-devel] gnumed not finding local db caused by not using correct config file
Date: Mon, 14 Jul 2008 15:10:23 +0200
User-agent: Thunderbird 2.0.0.14 (X11/20080629)

Karsten Hilbert schrieb:
On Mon, Jul 14, 2008 at 01:42:28PM +0200, Florian Hubold wrote:

When this is working, than the gnumed user for who i'm working on this problem can check. At the moment i can't login to the local db because i don't know the password,

Not yet. Currently i'm re-doing the layout of the gnumed-server package.
Does it matter whether gnumed-server is placed in /usr/lib/gnumed-server
or as you wrote in /usr/lib/Gnumed-server or in /usr/lib/GNUmed-server?

It shouldn't, no. "GNUmed" is the "official" spelling so
that may be a point to consider (but not mandatory, of
I kept the spelling like it was, GNUmed-server.
course).

My guess is that only the relative position of the symlink is important?
Correct.

Another question is, why the symlink in the first place? For what is it needed?
To make Python find the GNUmed modules. The bootstrapper can
run with either locally or globally installed modules.

Debian has a package gnumed-common which globally installs
the common GNUmed python modules such that both client and
server can find them (somewhere in /usr/.../site-packages).

Another approach is to do this as if one was doing this
manually after unpacking the tarball:

cd into the .../bootstrap/ directory and run the appropriate
shell script from there. The tarball contains all the needed
Python modules and also contains a symlink "Gnumed" at the
appropriate place. The scripts recreate that symlink just
for good measure ...

Now, why is the symlink necessary in the first place ?

Python modules are normally installed under site-packages/
or under a local directory. Inside each there will be
subdirectories for packages such as "Gnumed". This way
those subdirectories become namespaces in the Python world
and any Python script can do:

        from Gnumed import some_module

This "Gnumed" then needs to be found in the Python path
(sys.path from inside Python). Hence the Python-calling
GNUmed shell scripts put a symlink called "Gnumed" at the
appropriate level of the directory structure and also add
that directory to the Python path by including the directory
holding "Gnumed" into PYTHONPATH. The latter is an
environment variable read by the Python interpreter upon
startup which uses it to set its internal module lookup path
(accessible via sys.path from within Python).

Confused ?  I tried my best ;-)

Karsten

Well, the python modules from the gnumed-common package all go to
/usr/lib/python2.5/site-packages/Gnumed, so they are available without setting PYTHONPATH. But the gnumed-server files currently all go in /usr/lib/gnumed-server/server.
The symlink is also created during package install, it's named
/usr/lib/GNUmed-server/Gnumed. So either PYTHONPATH should
be set to /usr/lib/GNUmed-server/Gnumed or /usr/lib/gnumed-server/server
or all the python modules should be installed under /usr/lib/python2.5/site-packages/Gnumed
or /usr/lib/python2.5/site-packages/GNUmed-server or something the like
and a symlink should be created?

But even when no symlink and not PYTHONPATH is set,
why does the bootstrapping script fail in doing this correctly?

Another related question: Does PYTHONPATH take subdirectories into account,
or must it point directly to the directory with the modules.

And no, it was well explained, me didn't get confused :-D




reply via email to

[Prev in Thread] Current Thread [Next in Thread]