openshot.developers team mailing list archive

[TJ <ubuntu@xxxxxxxxxxx>]

On Mon, 2009-09-07 at 14:48 -0500, Jonathan Thomas wrote:
> As I've been playing around with the setup.py file, I'm starting to
> wonder if the classes/windows/language folders needs to be moved back
> to their original location.  The root of OpenShot is no longer a
> python program, since the python code has been moved under
> the /main/openshot/ folder.  That seems to be problematic with
> distutils, which wants to add just Python modules.

I'm not sure what you mean by this. Each of those sub-folders contains a
Python 'package' which is listed for distutils and will be included by
using:

packages = ['openshot', 'openshot.classes', 'openshot.language', 'openshot.windows']

>   I can tell distutils to add additional sub-folders (such as /glade
> and /glade/icons),

Yes, using this code construct?

glade_files = []
for filepath in glob.glob("openshot/windows/glade/*"):
...

>  but I can't seem to point at parent folders, such as /images,
> etc...).

For these locations and files you would use "./MANFEST.in". I created
one in my original packaging experimentation:

include AUTHORS COPYING README
recursive-include images *
recursive-include locale */LC_MESSAGES/openshot.mo
recursive-include profiles *
recursive-include themes *
recursive-include titles *
recursive-include transitions *
recursive-include openshot/windows/glade *

but I had to switch to using the "./setup.py" custom code when I
discovered that "MANIFEST.in" makes the resulting package incompatible
with python-support.

The reason is, python-support is designed to make the Python executable
code available to *all* the installed Python versions via
"/var/lib/python-support/pythonX.Y/<application>" when it does its magic
on the end-user's system. Usually it symbolic-links the files here for
each installed Python version (X.Y) into
"/var/lib/python-support/pythonX.Y/<application>".

However python-support *does not* symbolic-link non-Python files or
directories so the application ends up with files in two places and no
way to reconcile them, not to mention it being messy, if it relies upon
all its resources being positioned relative to a common base directory.

That is why I made the decision to have distutils install from the
distutils "setup.py" script into the Linux Filesystem Hierachy (LFH)
mandated location for architecture-independent files: "/usr/share/"

http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html

This is the policy of most distro's too.

By having distutils install to this location, when the Debian packaging
kicks in with python-support the "debian/rules" Makefile simply
over-rides the locations python-support would usually install to
("/usr/share/python-support/<application>") with:

DEB_PYTHON_INSTALL_ARGS_ALL += --install-lib=usr/share/openshot --install-script=usr/share/openshot

When the package arrives on the user's system and the python-support
hooks are triggered the installation of the python files is done in the
same place as the data files, "/usr/share/<application>".