Creating an application for Linux

[Mike Driscoll]

Hi,

My boss wants me to port one of my applications to Ubuntu. I
successfully ported it without too many headaches but now I need a way
to distribute it to people that may or may not already have the
dependencies my application requires. I'm a newb with Linux so I'm not
even sure what they call the distribution (rpms, deb, source code).

After browsing the various "installer" docs out there, it looks like
bbfreeze or PyInstaller might work, but I couldn't find any examples.
Any advice is appreciated. Thanks!

I am using Python 2.5.2 and this is a wxPython application with
SqlAlchemy and a few other external packages.

Mike

 

[lkcl]

hiya mike: where do i know you from? i've heard your name somewhere
and for the life of me can't remember where! anyway... onwards.

your simplest bet is to take advantage of the .deb install system,
which, if you follow that, will allow you to pull in all of the
dependencies _without_ screwing around with the ubuntu distribution,
or requiring that you build "special" versions of the dependencies.

so - your first port of call is to locate a similar app to your own
one:

apt-cache search wxwidgets
[rose-tinted filter on the results...]
cryptonit - A client side PKI (X.509) cryptographic tool
fontypython - A GUI tool to manage ttf fonts
jmdlx - jugglemaster deluxe using wxWidgets
wxmaxima - a wxWidgets GUI for the computer algebra system maxima
multiget - graphical download manager

then, do apt-cache show <packagename>, paying particular attention to
the dependencies. apt-cache show fontypython looks like a good
candidate.

so, do apt-get source fontypython (or other candidate)

also do apt-get build-essential dh-make dpkg-dev debutils python-dev
devscripts python-setuptools juuust for fun, but the essential ones
are probably dh-make and dpkg-dev.

then you have something to work from (an example - the source of the
deb-wrapped fontypython) and you will have most of the debian
developer utils etc. etc.

_then_ you go to e.g. oooo this:
http://www.pythonmark.com/python-library/debian/howto-build-a-debian-package-from-python-sources/
the preamble for which says "don't bother with that annoying ubuntu
python deb howto video, particularly on the basis that who gives a
stuff about _verbal_ instructions when you actually want stuff you can
READ!"



the most important thing that _you_ need to remember is that you
_must_ identify the correct libraries (and their debian packagenames -
can't bring myself to say ubuntu packagenames) and make damn sure that
you add them into the dependencies in the debian/control file.

do _not_ be tempted to "bundle" customised versions of python-
pysqlite, python-sqlalchemy etc. etc.

testing: you should really use a debootstrap absolute "basic"
environment (set up a chroot, or a virtual KVM or other virtual PC,
qemu, whatever, or even a real machine) do NOT do a "full" install of
ubuntu, do an absolute minimalist install (netbook, businesscard,
whatever).

.... and _then_ install your .deb (with dpkg -i) followed by apt-get -f
install (to pull in all of the dependencies).

then, use export DISPLAY=192.168.1.5:0.0 (adapt as necessary), run
xhost + on 192.168.1.5 (adapt as necessary), and _then_ fire up your
test app.

if you get a python library not found runtime error, you know that you
got your dependencies wrong, in the debian/control file.

if you install a "vanilla" ubuntu desktop, various other packages will
pull in the dependencies for you - and you will never find out if you
got all of the dependencies correct.

that having been said, if you don't _care_ about correctness, skip the
above six sentences

l.

 

[Mike Driscoll]

hiya mike: where do i know you from?  i've heard your name somewhere
and for the life of me can't remember where!  anyway... onwards.

I don't know...while your username looks vaguely familiar, I don't
think I've communicated with you recently. I spend most of my time on
the wxPython list now...

your simplest bet is to take advantage of the .deb install system,
which, if you follow that, will allow you to pull in all of the
dependencies _without_ screwing around with the ubuntu distribution,
or requiring that you build "special" versions of the dependencies.

so - your first port of call is to locate a similar app to your own
one:

apt-cache  search wxwidgets
[rose-tinted filter on the results...]
cryptonit - A client side PKI (X.509) cryptographic tool
fontypython - A GUI tool to manage ttf fonts
jmdlx - jugglemaster deluxe using wxWidgets
wxmaxima - a wxWidgets GUI for the computer algebra system maxima
multiget - graphical download manager

then, do apt-cache show <packagename>, paying particular attention to
the dependencies.  apt-cache show fontypython looks like a good
candidate.

so, do apt-get source fontypython (or other candidate)

also do apt-get build-essential dh-make dpkg-dev debutils python-dev
devscripts python-setuptools juuust for fun, but the essential ones
are probably dh-make and dpkg-dev.

then you have something to work from (an example - the source of the
deb-wrapped fontypython) and you will have most of the debian
developer utils etc. etc.

_then_ you go to e.g. oooo this:http://www.pythonmark.com/python-library/debian/howto-build-a-debian-...
the preamble for which says "don't bother with that annoying ubuntu
python deb howto video, particularly on the basis that who gives a
stuff about _verbal_ instructions when you actually want stuff you can
READ!"



the most important thing that _you_ need to remember is that you
_must_ identify the correct libraries (and their debian packagenames -
can't bring myself to say ubuntu packagenames) and make damn sure that
you add them into the dependencies in the debian/control file.

do _not_ be tempted to "bundle" customised versions of python-
pysqlite, python-sqlalchemy etc. etc.

testing: you should really use a debootstrap absolute "basic"
environment (set up a chroot, or a virtual KVM or other virtual PC,
qemu, whatever, or even a real machine) do NOT do a "full" install of
ubuntu, do an absolute minimalist install (netbook, businesscard,
whatever).

I thought the general practice was to test on the closest software/
hardware combo that your application was most likely to run on. I have
heard of doing testing on the lowest common denominator before though.
Unfortunately, I don't have time to set up a bare-bones VM since we're
closing soon, but I may give this a go on Friday and report back.

... and _then_ install your .deb (with dpkg -i) followed by apt-get -f
install (to pull in all of the dependencies).

then, use export DISPLAY=192.168.1.5:0.0 (adapt as necessary), run
xhost + on 192.168.1.5 (adapt as necessary), and _then_ fire up your
test app.

if you get a python library not found runtime error, you know that you
got your dependencies wrong, in the debian/control file.

if you install a "vanilla" ubuntu desktop, various other packages will
pull in the dependencies for you - and you will never find out if you
got all of the dependencies correct.

that having been said, if you don't _care_ about correctness, skip the
above six sentences

l.

Thanks for the instructions.

Mike

 

[lkcl]

I don't know...while your username looks vaguely familiar, I don't
think I've communicated with you recently. I spend most of my time on
the wxPython list now...

i think it might be from my old school - i could be confusing you
with
someone, though - "gary driscoll", perhaps? anyway, never mind

I thought the general practice was to test on the closest software/
hardware combo that your application was most likely to run on.

that you should do as well you should be able to either upgrade
the bare-bones version using "tasksel install desktop" or just...
what-the-heck, install on a vanilla combo.

http://archive.ubuntu.com/ubuntu/dists/intrepid/main/installer-i386/current/images/netboot/

archive.ubuntu.com appears offline at the moment - maybe it'll be
back later. i recommend you go for the mini.iso

I have
heard of doing testing on the lowest common denominator before though.
Unfortunately, I don't have time to set up a bare-bones VM since we're
closing soon, but I may give this a go on Friday and report back.

ok - the issue that you will face if you _don't_ do a LCD test is
that
should ubuntu get upgraded, and one of the packages that _used_ to
pull
in a dependency [that you missed] no longer does so...

 

[Mike Driscoll]

 i think it might be from my old school - i could be confusing you
with
 someone, though - "gary driscoll", perhaps? anyway, never mind



 that you should do as well  you should be able to either upgrade
 the bare-bones version using "tasksel install desktop" or just...
 what-the-heck, install on a vanilla combo.

 http://archive.ubuntu.com/ubuntu/dists/intrepid/main/installer-i386/c....

 archive.ubuntu.com appears offline at the moment - maybe it'll be
back later.  i recommend you go for the mini.iso

Ok...thanks for the info!

I have
heard of doing testing on the lowest common denominator before though.
Unfortunately, I don't have time to set up a bare-bones VM since we're
closing soon, but I may give this a go on Friday and report back.

 ok - the issue that you will face if you _don't_ do a LCD test is
that
 should ubuntu get upgraded, and one of the packages that _used_ to
pull
 in a dependency [that you missed] no longer does so...

I see. I had hoped that there was a way to create a frozen application
like I do with py2exe on Windows so I wouldn't have to worry about a
Linux upgrade breaking my application. I've been told that PyInstaller
might do the trick too. Either way, I'll post the solution that works
for me.

Happy New Year!

Mike

 

[lkcl]

i think it might be from my old school - i could be confusing you
with
someone, though - "gary driscoll", perhaps? anyway, never mind

that you should do as well you should be able to either upgrade
the bare-bones version using "tasksel install desktop" or just...
what-the-heck, install on a vanilla combo.

archive.ubuntu.com appears offline at the moment - maybe it'll be
back later. i recommend you go for the mini.iso

Ok...thanks for the info!

ok - the issue that you will face if you _don't_ do a LCD test is
that
should ubuntu get upgraded, and one of the packages that _used_ to
pull
in a dependency [that you missed] no longer does so...

I see. I had hoped that there was a way to create a frozen application
like I do with py2exe on Windows so I wouldn't have to worry about a
Linux upgrade breaking my application. I've been told that

ok - to do _that_, you will have to download copies of every single
library that your app uses, compile them specially into a customised
location (/opt/local or /usr/local); you will have to then make sure
that PYTHONPATH environment variable is set to point to the
locations. from a random manual somewhere:

The PYTHONPATH variable can be set to a list of paths that will be
added to the beginning of sys.path. For example, if PYTHONPATH is set
to "/www/python:/opt/py", the search path will begin with ['/www/
python', '/opt/py']. (Note that directories must exist in order to be
added to sys.path; the site module removes paths that don't exist.)

having multiple copies of python libraries on your system was exactly
the thing that i recommended that you _not_ do

because you _still_ have to install them, and the process to do _that_
easily, on ubuntu, is "apt-get install" - so why bother duplicating
that effort?

path of least resistance says "go with the debian flow". well... it
does in my book, anyway

l.

 

[excord80]

You might find this recent blog post interesting:

http://www.mechanicalcat.net/richard/log/Python/Sane_Python_application_packaging__initial_solution