← Back to team overview

openshot.developers team mailing list archive

Re: Packaging related questions

 

I looked into Python distutils and python-support when I was first
researching how to build some .deb packages.  I was quickly defeated by
those tools, and choose to create the .debs using more traditional ways...
such as "$ dpkg -b".  Since OpenShot is a desktop application, and not just
a Python library, I wonder if the python-support command even applies???
Sorry I'm not more help.

And I agree with you that the MLT Python bindings need to be installed to
the /site-packages, since it is a system-wide library that anyone should be
able to use with Python.

Thanks,
-Jonathan


On Tue, Aug 25, 2009 at 2:08 PM, TJ <ubuntu@xxxxxxxxxxx> wrote:

> On Tue, 2009-08-25 at 12:35 -0500, Jonathan Thomas wrote:
> >
> >         1. What version(s) of Python are required (i.e; >= 2.2,
> >         >=2.4) ?
> >         I've only tested on Python 2.5 and greater.  It might work
> >         with older version too, but that's a bit of an unknown.
>
> OK. I suppose once we've got the packages sorted out it'll be trivial to
> test against the different Python versions in chroot or virtual
> environments.
>
> >         2. install/postinst.py is trying to copy MLT python bindings
> >         (mlt.py,
> >         _mlt.so, mlt_wrap.o) which don't exist (at least the source
> >         doesn't) -
> >         are these no longer required?
> >         These 3 files are installed by my custom MLT .deb installer.
> >         After building MLT, I ran the following commands to generate
> >         the swig Python bindings:
> >
> >         $ cd ~/mlt/src/swig/python
> >         $ sudo bash build
> >
> >         Then these 3 files need to be copied into the Python path
> >         (i.e. the site-packages or dist-packages folders, or any other
> >         folder in the Python path).  Ideally, the MLT Python bindings
> >         would be packaged separately (i.e. something like
> >         mlt-python-bindings, or what ever).  If done correctly, you
> >         can open up the Python shell, and type "import mlt", and it
> >         will not throw an error.  This has always been one of the more
> >         difficult steps to automate in my build wizard and in the
> >         packaging I've attempted so far. =)
>
> Ahh thanks! I have the dependency .deb files unpacked from the archive
> but when I looked through the list of files I missed these three - I've
> just looked again and seen them.
>
> Here's my initial ideas (which might change in the testing):
>
> Your idea for a "python-mlt-bindings" package is ideal. In the "mlt"
> source package's "debian/rules" file "swig/python/build" can be executed
> and then the new binary package "python-mlt-bindings" in
> "debian/control" will install the resulting files.
>
> I'm not a great Python expert but I'd guess as these are public
> interfaces to system libraries they should be installed as site-packages
> so they are available to all python apps that want them?
>
> >         3. install/openshot.dpm isn't installed - should it be, or is
> >         it not
> >         required?
> >         This file can be ignored.  I'm going to delete it from the
> >         trunk.
>
> Thanks, one less to worry about.
>
> >         5. install/openshot.desktop contains absolute paths for icons
> >         to /usr/local/share/* locations which need to be become
> >         agnostic. The
> >         icon should be installed in the system icons directory. If the
> >         logo icon
> >         is referenced from the program code that will need updating to
> >         detect
> >         the system path location and concatenate it with the filename.
> >         This is the only path in OpenShot that is hard-coded.
> >         Everywhere inside OpenShot we do exactly like you suggest, and
> >         concatenate the system path with the filename.  I just didn't
> >         know where to install this icon, and how to refer to it's path
> >         on the .desktop file.
>
> I seem to recall seeing how to obtain the system's pixmap/icon path in
> the distant past but can't remember the specifics. I'll explore this one
> and get back to you unless you figure it out first :)
>
> >
> >         6. Two directories (thumbnail/ and queue/) appear to be
> >         per-user
> >         'runtime' rather than 'build-time' requirements. This suggests
> >         they
> >         should be created in the user's home directory:
> >         ~/.openshot/thumbnail/
> >         and ~/.openshot/queue/.
> >         The primary reason for this would be user permissions to the
> >         applications' installation directory are restricted to read
> >         +execute.
> >         This requires programs changes so we'll need to liaise on this
> >         since the
> >         program would need to ensure the directories are created at
> >         each launch
> >         - the Debian package wouldn't have anything to do with them.
> >         I will go ahead and move these folders into the home
> >         directory.  This should be a fairly easy change.  OpenShot
> >         will create these folders at runtime, so there shouldn't be
> >         any problems.
> >
>
> Thanks, that has removed another potential headache.
>
> Another question on Python packaging:
>
> 7. Based on Debian recommendations I'm attempting to use the
> "python-support" package to automate creation of a
> python-version-agnostic .deb. It uses the Python "distutils" setup.py
> services to build the target installation image.
>
> This appears to be built successfully in that all the files I'm
> expecting to see are included.
>
> I'm currently confused though, since the files are installed to
> "/usr/lib/python-support/openshot/". This makes sense based on the
> purpose of python-support, but I cannot figure out how, at install time,
> the files are built and installed to their final resting place, which I
> assume will be /usr/lib/openshot/ or something similar.
>
> Anyone having encountered the Python distutils and python-support please
> shout out - you might save me some frustration!
>
>
>

Follow ups

References