Creating an application for Linux

Discussion in 'Python' started by Mike Driscoll, Dec 31, 2008.

  1. 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
    Mike Driscoll, Dec 31, 2008
    #1
    1. Advertising

  2. Mike Driscoll

    lkcl Guest

    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.



    On Dec 31, 9:06 pm, Mike Driscoll <> wrote:
    > 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, Dec 31, 2008
    #2
    1. Advertising

  3. On Dec 31, 3:36 pm, lkcl <> wrote:
    > 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
    Mike Driscoll, Dec 31, 2008
    #3
  4. Mike Driscoll

    lkcl Guest

    On Dec 31 2008, 9:54 pm, Mike Driscoll <> wrote:
    > On Dec 31, 3:36 pm,lkcl<> wrote:
    >
    > > 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...


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

    > > 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.


    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...
    lkcl, Jan 1, 2009
    #4
  5. On Jan 1, 7:47 am, lkcl <> wrote:
    > On Dec 31 2008, 9:54 pm, Mike Driscoll <> wrote:
    >
    > > On Dec 31, 3:36 pm,lkcl<> wrote:

    >
    > > > 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...

    >
    >  i think it might be from my old school - i could be confusing you
    > with
    >  someone, though - "gary driscoll", perhaps? anyway, never mind :)
    >
    > > > 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.

    >
    >  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
    Mike Driscoll, Jan 1, 2009
    #5
  6. Mike Driscoll

    lkcl Guest

    On Jan 1, 4:44 pm, Mike Driscoll <> wrote:
    > On Jan 1, 7:47 am,lkcl<> wrote:
    >
    >
    >
    > > On Dec 31 2008, 9:54 pm, Mike Driscoll <> wrote:

    >
    > > > On Dec 31, 3:36 pm,lkcl<> wrote:

    >
    > > > > 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...

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

    >
    > > > > 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.

    >
    > > 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


    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.
    lkcl, Jan 2, 2009
    #6
  7. Mike Driscoll

    excord80 Guest

    excord80, Jan 2, 2009
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. U. George
    Replies:
    4
    Views:
    826
    U. George
    Aug 11, 2005
  2. pk
    Replies:
    3
    Views:
    789
    Roedy Green
    Feb 13, 2006
  3. Replies:
    10
    Views:
    843
    Mike Meyer
    Aug 19, 2005
  4. Guillaume Marcais

    Creating "windows binaries" on Linux

    Guillaume Marcais, Jan 23, 2006, in forum: Ruby
    Replies:
    2
    Views:
    94
    Guillaume Marcais
    Jan 25, 2006
  5. Krishna Chaitanya
    Replies:
    1
    Views:
    133
    Krishna Chaitanya
    Feb 27, 2009
Loading...

Share This Page