DirectoryStructure

The following is a collection of pieces of discussion, for possible reference value. They may not correctly reflect current status or plan.

From Ian: We still haven't resolved the default install location issue. I vote for /usr/share/gnumed/, mainly because that's Debian policy, and escapes Python upgrade traumas.

From David: How can putting things in /usr/share be official debian policy? I can see /usr/lib/gnumed but not /usr/share, according to the FHS. It should be possible to put the scripts anywhere, even /opt if someone so desires, or in their home_dir (if you have no root access on a certain PC), or /usr/share/local, or whatever. About the debian packages, I forget why was some of the *.py files going into site-packages and some of it in /usr/share? Just using 'setup.py install' with the --prefix options will put gnumed anywhere you want it to be.

From Andreas: Well, because I'm to stupid to understand the logic behind sorting the source into business, wxpython, etc I left the files where they are in the source. Once I understand the logic I want to move them under a "logical" directory under site-packages. You exactly pointed to the problem I have with GnuMed packaging. As long is I was not able to find out which Python file is used by which Module I just left the files in the "untouched pool". Moreover I have to admit that I did not looked into GnuMed for several weeks and will not be able to do it before the first weekend in March. Perhaps something has been clarified. To be honest, menti gevery single file in *.install has the disadvantage that I might miss some new files and this will be changed in the future. Just regard these *.install files as my personal TODO-List and not as sane packaging.

From Karsten (March 8, 2004): I have changed the import regime to using packages:

from Gnumed.<pycommon|business|wxpython> import <foo>

For that to work one needs to create

    .../site-packages/Gnumed/

and link

    client/pycommon/
    client/wxpython/
    client/business/
    client/__init__.py

into it.
We need to find some magic now to set PYTHONPATH appropriately in gnumed-from-cvs-tree.sh such that things still work. The GUI comes up albeit no plugins will get loaded due to unresolved import statements. Please convert them as needed. Also, the

if __name__ == __main__:
    sys.path.append()

stuff can go now (but may need a replacement here and there).

• gnumed/
  • gnumed/
    • client
      • bitmaps
      • business
      • doc
      • etc
      • locale
      • pycommon (was python-common)
        • (from Andreas) the following modules had to be moved to common between server and client:
        • gmBackendListener.py
          • Not needed anymore (karsten Feb 25.04)
        • gmCfg.py
          • from Ian feb 24/04 --> implies this needs moving or copying to server?
          • "the only dependencies of this script from python-common are gmLog and gmCfg, both pretty stable now." - Well, they may have indirect dependancies.--Karsten Feb 25/04
          • pyPgSQL acc to Karsten is preferred to the python dbapi module if you need the backend listener (or the gmCfg stuff on which dependancy Karsten wonders Feb 25/04 we should remove)
          • from Horst Feb 25/04 We could implement the backend listener as a simple XML-RPC service on the backend - come to think of it, we could move all pyPgSQL functionality to such a service as well, reducing the dependencies considerably (no mxDateTime and no PyPGSQL on the client side any more). The performance loss through XML-RPC could be regained by having cached business objects within the XML-RPC service on the server side. Far less network traffic if done in a smart way. Signals can be moved into the client using a RPC server on both ends, working away as a separate thread. "Server side server" calls "client side server" for notification, client side server puts message into the dispatcher queue. You are not going to have hundreds of backend notifications per second even in large implementations, hence the overhead doesn't matter much.
          • from Ian: we need gmCfg to read the config file, we need the config file to find gmCfg....Solutions:
            • from Karsten: gmCLI will afford us to find the conf files if they are in non-standard places. Only if they are in any of the standard places will gmCfg hoist itself out of the waters like Munchhausen.
            • - inline the code into gnumed.py (~200 lines)
            • - use Python's own ConfigParser class.
              • from Karsten: insufficient ... (although gmCLI might get replaced one day due to Python's CL parsing having got better since optik has been made a core module)
        • gmCLI.py
          • lazied in gmCfg (karsten Feb 25.04)
        • gmDispatcher.py
          • ? (karsten Feb 25.04)
        • gmExceptions.py
          • ? (karsten Feb 25.04)
        • gmI18N.py
          • ? (karsten Feb 25.04)
        • gmLoginInfo.py
          • ? (karsten Feb 25.04)
        • gmLog.py
          • from Ian feb 24/04 --> implies this needs moving or copying to server?
          • "the only dependencies of this script from python-common are gmLog and gmCfg, both pretty stable now." - Well, they may have indirect dependancies.--Karsten Feb 25/04
        • gmPG.py
          • lazied in gmCfg (karsten Feb 25.04)
      • wxpython
  • device-drivers
  • dists
    • Debian
    • Knoppix
    • Windows
    • XdtViewer
  • html
    • developers-manual
  • server
    • • gmAuditSchemaGenerator.py - Ian feb 24/04 implies not needed here?
        • sjtan (Feb 24/04) did a bash configuration script for the audit trigger from gmAudit..Generator using sed, psql and `..`
      • gmScoringSchemaGenerator.py - Ian feb 24/04 implies not needed here?
    • bootstrap
      • scripts now feature "nice mode", per Ian feb 24/04
    • corba
    • locale
    • sql
      • country.specific
      • test-data
    • x_db_fk_verifier
  • test-area
    • dead-wood
    • note from karsten Feb 25/04: Import in various files in test-area is still broken but intentionally so.

Notes

• The syntax of how the files import modules would have to change, but after that the sys.path.append could all be obsoleted I think. --DavidGrant
• No, GNUMED_DIR is still useful. The minute you remove it someone will pop up and say: Foo doesn't do Bar. I need to control where GnuMed looks for files explicitly. How about using it for finding the non-python files (if a couple standard places don't work) ? -karsten
• I would rely on /usr/share/gnumed as default which can be overriden by /etc/gnumed/foo.conf while this can be overriden by GNUMED_DIR - Andreas Feb 24/04
• from Karsten Feb 25, 2004 Then $GNUMED_DIR isn't even needed anymore ... Simply start the client with

  --conf-file=/my/strange/path/to/gnumed.conf and you are set. gnumed.conf then of course needs to do

  [client] resource path = /some/nice/place/in/*shudder*/opt/gnumed/