3

I've recently been doing quite a bit of coding using quickly and GTK 3. Its great and i'm happy with some of the results, but now i'd like to share my apps with people running windows or mac. Is there any way to make a windows installer of some kind, or will i have to hold their hand as they try to install the various libraries etc? Thanks in advance.

4 Answers 4

6

GTK3 is the hard bit... I'll get to that in a second...

Wrapping up a Python project for Windows is actually quite easy if you use something like py2exe or pyinstaller. There are also commercial options out there but it's been such a long time I can't remember their names.

Either way, you end up an entire Python environment with everything you need baked in. The user just runs it.

Now back to the toolkit. GTK3 can be installed on Windows but it's not a thriving or mature cross-platform toolkit. There are some questions about this on StackOverflow but I don't know what bindings they provide. They're probably not suitable for Python but I hope I'm wrong. In short - you probably don't want to be using GTK3 for a cross-platform application.

Past that, you're left looking for an alternative. Three popular options:

2
  • If you're doing all three major platforms, PyInstaller is probably better for you than py2exe.
    – Oli
    Aug 31, 2012 at 9:36
  • You get an upvote for saying avoid the complexity, but it is possible to cross-compile gtk3/pygi and use a portable python instance with the wrapper built in(buggy though) opensourcepack.blogspot.com/p/pygobject-pygi-aio.html Aug 31, 2012 at 10:34
3

I've added building instructions for win32 at gnome live page of PyGobject https://wiki.gnome.org/PyGObject#Building_on_Win32_with_cx_freeze

3
  • 1
    Welcome to Ask Ubuntu! Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference.
    – guntbert
    Aug 28, 2013 at 6:18
  • 1
    Thanks, so you are basically telling me that is good practice to duplicate the answer, so if for any reason I will have to modify the wiki page @ live.gnome.org I have to remember to come back here and modify it as well? To be honest it looks pretty silly to me, just like duplicate code.
    – gianmt
    Aug 30, 2013 at 17:08
  • No, you misunderstood - "essential parts" doesn't mean "verbatim duplicate" but please give an overview - we do hope that both this site and your page live forever but just in case ...
    – guntbert
    Aug 30, 2013 at 17:13
0

You can make .deb packages, where if there are dependecies involved, they can be specified, just like a .deb package you normally install.

Making a package is nothing so simple that one could teach you here in 1 or 2 commands, you need to read something about this, so i recommend you read this:

http://developer.ubuntu.com/packaging/html/

Basic info from that site:

Starting a Package

bzr-builddeb includes a plugin to create a new package from a template. The plugin is a wrapper around the dh_make command. You should already have these if you installed packaging-dev Run the command providing the package name, version number, and path to the upstream tarball:

$ sudo apt-get install dh-make
$ cd ..
$ bzr dh-make hello 2.7 hello-2.7.tar.gz

When it asks what type of package type s for single binary. This will import the code into a branch and add the debian/ packaging directory. Have a look at the contents. Most of the files it adds are only needed for specialist packages (such as Emacs modules) so you can start by removing the optional example files:

$ cd hello/debian
$ rm *ex *EX

You should now customise each of the files.

In debian/changelog change the version number to an Ubuntu version: 2.7-0ubuntu1 (upstream version 2.7, Debian version 0, Ubuntu version 1). Also change unstable to the current development Ubuntu release such as precise.

Much of the package building work is done by a series of scripts called debhelper. The exact behaviour of debhelper changes with new major versions, the compat file instructs debhelper which version to act as. You will generally want to set this to the most recent version which is 8.

control contains all the metadata of the package. The first paragraph describes the source package. The second and and following paragraphs describe the binary packages to be built. We will need to add the packages needed to compile the application to Build-Depends:. For hello, make sure that it includes at least:

Build-Depends: debhelper (>= 8.0.0) You will also need to fill in a description of the program in the Description: field.

copyright needs to be filled in to follow the licence of the upstream source. According to the hello/COPYING file this is GNU GPL 3 or later.

docs contains any upstream documentation files you think should be included in the final package.

README.source and README.Debian are only needed if your package has any non-standard features, we don’t so you can delete them.

source/format can be left as is, this describes the version format of the source package and should be 3.0 (quilt).

rules is the most complex file. This is a Makefile which compiles the code and turns it into a binary package. Fortunately most of the work is automatically done these days by debhelper 7 so the universal % Makefile target just runs the dh script which will run everything needed.

All of these file are explained in more detail in the overview of the debian directory article.

Finally commit the code to your packaging branch:

$ bzr commit -m "Initial commit of Debian packaging."

Building the package

Now we need to check that our packaging successfully compiles the package and builds the .deb binary package:

$ bzr builddeb -- -us -uc
$ cd ../../

bzr builddeb is a command to build the package in its current location. The -us -uc tell it there is not need to GPG sign the compile. The result will be placed in ...

You can view the contents of the package with:

$ lesspipe hello_2.7-0ubuntu1_amd64.deb

Install the package and check it works:

$ sudo dpkg --install hello_2.7-0ubuntu1_amd64.deb

Next Steps

Even if it builds the .deb binary package, your packaging may have bugs. Many errors can be automatically detected by our tool lintian which can be run on both the source .dsc metadata file and the .deb binary package:

$ lintian hello_2.7-0ubuntu1.dsc
$ lintian hello_2.7-0ubuntu1_amd64.deb

A description of each of the problems it reports can be found on the lintian website.

After making a fix to the packaging you can rebuild using -nc “no clean” without having to build from scratch:

$ bzr builddeb -- -nc

Having checked that the package builds locally you should ensure it builds on a clean system using pbuilder. If you haven’t set up pbuilder-dist yet, do so now:

$ bzr builddeb -S
$ cd ../build-area
$ pbuilder-dist precise build hello_2.7-0ubuntu1.dsc

When you are happy with your package you will want others to review it. You can upload the branch to Launchpad for review:

$ bzr push lp:~<lp-username>/+junk/hello-package

Uploading it to a PPA (Personal Package Archive) will ensure it builds and give an easy way for you and others to test the binary packages. You will need to set up a PPA in Launchad then upload with dput:

$ dput ppa:<lp-username> hello_2.7-0ubuntu1.changes
2
  • 1
    I'm fairly sure this question is about packaging Python+GTK3 applications for Windows and OSX.
    – Oli
    Aug 31, 2012 at 9:43
  • 3
    This response is so off-topic. The question is about Windows...
    – Bobble
    Jan 1, 2013 at 15:23
0

There exists a tool py2exe which converts a python program into a standalone windows executable (including the python interpreter), which I think is what you are looking for.

This page specifically mentions packaging Gtk applications with this tool.

Doesn't help with OS X though I'm afraid.

1
  • The py2exe examples are all for GTK2 (PyGTK is v2 only AFAIK)
    – Oli
    Aug 31, 2012 at 9:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .