fixes problems for users with read-only home directories. Plus,
it's easy enough for the user to create the file when it's
needed

Substitutes DEBIAN_STYLE_LIBEXEC flag and manages location and name of lib and libexec folders on Debian/Ubuntu-based systems

since the ost startup script lives in the same directory as the
top-level ost modules (python{version}/site-packages/ost), the
directory got automatically added to sys.path. That's bad for
several reasons I don't want to go in right now (see discussion
on the mailing list). Instead of passing the script as a script
name to execute, we now use execfile with the startup script.
This circumvents addition of the directory to the path and
makes Gabriel smile again.

Valerio Mariani authored 12 years ago and Bienchen committed 12 years ago

Commited patched file by mistake

Valerio Mariani authored 12 years ago and Bienchen committed 12 years ago

Thanks Tobias for diagnosing the problem

Up until Python 2.6, MacOS X systems were detected as 32 bit
platforms. Now, they are detected as 64bit systems. This
caused sys.path to be wrong and the ost module could not
be imported

Commited patched file by mistake

Commited patched file by mistake

Thanks Tobias for diagnosing the problem

Thanks Tobias for diagnosing the problem

there are now three startup files; ost_startup.py (former init_cl.py) initializes non-gui ost; dng_startup (former init.py) initializes dng; and gosty_startup initializes gosty (some issues remain what to put into dng_startup as opposed to gosty_startup). also, files are now properly placed into site-packages/ost (on osx and linux)

changed python unit tests to run with python instead of ost

Remarks
-------

Python unit tests using blast, clustalw or the compound lib where
skipped on my system. There might be still some missing imports in
these tests.