Re: Python Bindings for MLT

[Jonathan Thomas <jonathan.oomph@gmail.com>]

I solved this problem also.  I needed to change my setup.py to include a mlt folder, not a mlt-python folder.  Also, I modified the __init__.py to include the following code:
"from mlt import *"

Now when I install the package, python-support puts everything in the /usr/lib/pymodules/ folder, which is in the python path, and then my "mlt" folder and the customized __init__.py file work great.  

Now I am able to import the mlt library as expected:
>> import mlt

Sorry for so many stupid questions.  I tried to explain my solutions so they are documented for the next person with my questions. =)  

Thanks,
-Jonathan

On Mon, Dec 28, 2009 at 4:24 PM, Jonathan Thomas <jonathan.oomph@gmail.com> wrote:

I have figured out the answer to my question.  Python-support correctly adds my folder and files to the Python path.  This changes the way I need to import the python module from
>> import mlt
to
>> import mlt-python.mlt

However, "mlt-python" does not appear to be a valid module name for Python.  It does not like the "-" character.  Is there a way to tell python-support what the name of the folder should be?  For example,

Instead of this folder:  /usr/lib/pymodules/python2.6/mlt-python/
Use this folder:  /usr/lib/pymodules/python2.6/mlt/

Thanks in advance!
-Jonathan Thomas
 

On Mon, Dec 28, 2009 at 2:48 PM, Jonathan Thomas <jonathan.oomph@gmail.com> wrote:

Jakub,
Thanks for the advice.  I have removed the postinst script and the DEB_PYTHON_INSTALL_ARGS_ALL line.  I have also contacted the MLT packagers, but I'm not confident they will include the Python bindings in their packages.

Here is a dumb question.  After installing the DEB file, it moves all of the correct files to /usr/lib/pymodules/python2.6/mlt-python.  However, when I fire up python, it is unable to import mlt.

For example:
>> import mlt
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named ml

If I launch the Python interpreter from /usr/lib/pymodules/python2.6/mlt-python, it works just fine.  It is acting like my public Python module is not in the sys.path.  I assumed because /usr/lib/pymodules/python2.6/ was in the sys.path, that this would work.

Am I missing something?

Thanks,
-Jonathan

On Thu, Dec 17, 2009 at 6:38 AM, Jakub Wilk <ubanus@users.sf.net> wrote:

Hello,

* Jonathan Thomas <jonathan.oomph@gmail.com>, 2009-12-15, 13:16:

I have done my best to package the MLT Python bindings (which were generated
using Swig), and I have published to my own

PPA<https://launchpad.net/%7Ejonoomph/+archive/openshot-edge>(hosted

on LaunchPad).  I am fairly certain that my build script needs to be
improved.  For example, I never could figure out how to copy the MLT Python
bindings to the /site-packages/ folder, so I created a postinst file...
which can't be the best way.

Right, that's not event an acceptable way. Those files don't need to be installed into /site-packages/, python-support should take care to put them in the right place once you remove maintainer scripts and the DEB_PYTHON_INSTALL_ARGS_ALL line from debian/rules.

Anyway, these bindings should not have a separate source package. Just ask mlt maintainers (preferably via a bug report) to build binary package with Python bindings out of their source.

--
Jakub Wilk

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBCAAGBQJLKiYwAAoJEC1Os6YBVHX1ve4P/3661p1kp2xbF2j/LtQ0oA1o
4goSpI+rg2Fl+zHi4e4VOexhSXrvw2WaaHEXofzVFvcoC3Osgz/H2iLzm6DkL3PI
5MrlLcAYU/ZP4ahRA20HHiQhvXcZMWgrN+2uLzu4l8tMAexMtNfQ/xPiceKV3kL9
KDHS3X6Rk7jG6vsnPVI7uGztgjprSr6MG3Ks6NoLICgPCk8SUQ1P+okaP99H/Q0f
6+pbDYiK5g5/v4dw/iIXIJHMsaawh6F+zphvEg7TMVJuWJ9zGPORmDNMon0z3+h0
Q4xTD2qemnL3ybleKVvcF40p/po4HGk+IYaaqM4HQ0DudH8gSkKoFp0Hzx12ZQ34
XMxHL8dNAnYPqlvubgxjQqctmAVm660dqExKQDjPMQytpjntyVPAKQGJdEOBCPwY
Chj5nn36/dAUH9HTd4f2583nRfcCX5BbPdhFbADPAoen8Fbehl4GBGYSoUsJ7COT
sjvXpRKkMxSUhXGXt6k4Gs63YrQ80rZwJPhYM/vtaKzBeLyq/5Acc7n2Ba8CIU1Y
h42OQgG5bhyAFUGdiomUd1eweSfUZ04FZSXHfaVwqUuWeeOYZacQiUj111ygdMTS
vbZ4EU/MR+xc5p6mJNqyJTBI9TrqV1eHfsgjLXTi9J8e3IFDkEt7Nhdweuoid4Gp
hFNHiCz04pdpj/8HWWrS
=kneW
-----END PGP SIGNATURE-----