How to distribute python GTK applications?

Question

This is in correlation with the previous question I asked here. My aim is to create and package an application for easy installation in Ubuntu and other debian distributions. I understand that the best way to do this is by creating .deb file with which users can easily install my application on their system.

However, I would also like to make sure my application is available in multiple languages. This is why I raised the question before which you can read here. In the answers that were provided, I was asked to use disutils for my packaging. I am however missing the bigger picture here.

Why is there a need to include a setup.py file when I distribute my application in .deb format?

My purpose is to ensure that users do not need to perform python setup.py to install my application but rather just click on the .deb file. I already know how to create a deb file from the excellent tutorial available here. It clearly shows how to edit rules, changelog and everything required to create a clean deb file.

You can look at my application source code and folder structure at Github if it helps you better understand my situation.

Please note I have glanced through the official python documentation found here. But I am hoping that I would get an answer which would help even a lame man understand since my knowledge is pretty poor in this regard.

Answer 1

You don't actually need to use a build system to package your application.

However, not using a build system will mean that you will have to write all of the functionality that a build system provides 'for free' from scratch. Not only will this be more work for you, but you'll be on your own. That is, it's much better to rely on proven tools which are well backed by an active community than starting and maintaining build and installation scripts, unless you know very well what you're doing and you purposefully want to avoid using a build system.

A build system will also move great part of the logic to do the build and installation to the system itself, rather than on the packaging. This results in a cleaner and simpler debian/rules file, which will be much easier to maintain.

Now for your Python app, we did not ask to use a build system on your other question, but we did recommend it. And that was distutils/distutils-extra, as they are the most common ones and with better support for Python. There are also other out there, such as autotools, but they are generally more complex to set up for Python software.

Note that it's not either/or. That's where the confusion might come from. A build system and packaging are complementary. The packaging makes use of the build system to create the package. So it's not that by adding a e.g. setup.py file you'll force your users to use it. Rather on the contrary, you'll make it easier to create a .deb package out of your app, which users can install by just clicking it.

So here are the facts, you do not need to use a build system, but it will greatly help you in creating and maintaining your package. Your choice :)

Answer 2

Do you want to only, ever, make your application available as a .deb package? what about people running other Linux distributions (Fedora, Gentoo) or even Windows?

Debian's packaging philosophy allows you to package and distribute software on .debs, while also maintaining a "pristine" source that can be used with other distribution methods (even people downloading a tar.gz and doing python setup.py. A lot of Debian's packaging tools assume (and work best with) a source tree that adheres to standard ways of being built, be it ./configure; make; make install, python setup.py, perl Makefile.PL; make install, or what not.

To achieve this, Debian's packaging tools know a lot about (and work in conjunction with) building frameworks from other languages. And if you use them, you get a lot of stuff for free. One example is the i18n stuff you were mentioning on your previous question; if you do it the Python/setup.py way, your Debian package will pick up on it almost automagically. If you have source that uses ./configure and adheres to GNU standards, packaging it is really easy.

Personally I think the end goal is allowing you to use an existing building framework/methodology in order to help your software provide desired installation features, without locking you up into a particular way of packaging your binaries. Remember that in the Linux world, there's a lot of choice and people will appreciate your application supporting that choice by adhering to standard ways of being built.