Mailman 3 Distributing Python-programs to Ubuntu users - Distutils-SIG

Distributing Python-programs to Ubuntu users

Olof Bjarnason

25 Sep 2009 25 Sep '09

1:23 a.m.

Hi! I'm new at the mailing list. I write small games in Python/PyGame. I want to find a way to make a downloadable package/installer/script to put on my webpage, especially for Ubuntu users. I've skimmed a couple of tutorials on how to generate .deb-files, but, wow, it's a whole new skill set to do that! Does anyone have any hint on a more economic way of creating single-file distribution packages for Python+PyGame projects? Maybe some GUI-tool that automates the .deb file creation process, but targetting Python specifically and not C++. I've looked at Ubuntu's PPA system, didn't find it end-user-friendly enough. Also, the Quickly project was too invasive on the way I like to develop software (it took over the bzr/lp tools; I want to control that). /Olof

Show replies by date

Ben Finney

25 Sep 25 Sep

1:52 a.m.

Thanks for moving the discussion to this forum, where it's better suited. I'll reprise my existing reply again here for this new thread. Olof Bjarnason writes:

...

I'm new at the mailing list. I write small games in Python/PyGame. I want to find a way to make a downloadable package/installer/script to put on my webpage, especially for Ubuntu users.

The primary means of distributing your work to the outside world should, first, be a working Distutils ‘sdist’ (“source distribution”). This allows the work to be installed via ‘python ./setup.py install’, with installation options customisable by those users who want to do so. An important set of users who might (read “will”) want to customise installation options is that set of users who can package your work for specific distributions. They will take the Distutils configuration as a starting point, and apply OS-specific packaging from that point. You would do well to be familiar with the Filesystem Hierarchy Standard URL:http://www.pathname.com/fhs/ and specifications for desktop applications URL:http://www.freedesktop.org/wiki/Specifications as they apply to whatever programs you're making. Many aspects of these (Especially of the FHS) are taken care of for you by the Distutils infrastructure, but many are not.

...

I've skimmed a couple of tutorials on how to generate .deb-files, but, wow, it's a whole new skill set to do that!

Right. It's a separate body of research, learning, and discipline to make packages that operate smoothly on a particular operating system. If you're not interested in that, please don't do a half-hearted job; instead, focus on making a great program, and leave the job of making a great package to someone better placed to do it.

...

Does anyone have any hint on a more economic way of creating single-file distribution packages for Python+PyGame projects? Maybe some GUI-tool that automates the .deb file creation process, but targetting Python specifically and not C++.

Those tools that exist do more harm than good, in my opinion: they either do very little to help, or they necessarily make guesses about the right thing to do. The policies and specifications change from time to time, and such automated tools cannot hope to be both comprehensive and up-to-date. As someone who has some familiarity with the OS packaging process, I would beg you not to make OS-specific packages without a good, current understanding of the OS packaging policy you're targeting. If that doesn't sound like fun, just concentrate on making your program great, standards-compliant, and responsive to bug reports — especially from OS package maintainers. That will make it much more attractive and give a much better change of having a good range of OS-specific packages. -- \ “Technology is neither good nor bad; nor is it neutral.” | `\ —Melvin Kranzberg's First Law of Technology | _o__) | Ben Finney

Olof Bjarnason

2:35 a.m.

2009/9/25 Ben Finney :

...

Thanks for moving the discussion to this forum, where it's better suited. I'll reprise my existing reply again here for this new thread.

Olof Bjarnason writes:

...
I'm new at the mailing list. I write small games in Python/PyGame. I want to find a way to make a downloadable package/installer/script to put on my webpage, especially for Ubuntu users.

The primary means of distributing your work to the outside world should, first, be a working Distutils ‘sdist’ (“source distribution”). This allows the work to be installed via ‘python ./setup.py install’, with installation options customisable by those users who want to do so.

An important set of users who might (read “will”) want to customise installation options is that set of users who can package your work for specific distributions. They will take the Distutils configuration as a starting point, and apply OS-specific packaging from that point.

You would do well to be familiar with the Filesystem Hierarchy Standard URL:http://www.pathname.com/fhs/ and specifications for desktop applications URL:http://www.freedesktop.org/wiki/Specifications as they apply to whatever programs you're making. Many aspects of these (Especially of the FHS) are taken care of for you by the Distutils infrastructure, but many are not.

...
I've skimmed a couple of tutorials on how to generate .deb-files, but, wow, it's a whole new skill set to do that!

Right. It's a separate body of research, learning, and discipline to make packages that operate smoothly on a particular operating system. If you're not interested in that, please don't do a half-hearted job; instead, focus on making a great program, and leave the job of making a great package to someone better placed to do it.

...
Does anyone have any hint on a more economic way of creating single-file distribution packages for Python+PyGame projects? Maybe some GUI-tool that automates the .deb file creation process, but targetting Python specifically and not C++.

Those tools that exist do more harm than good, in my opinion: they either do very little to help, or they necessarily make guesses about the right thing to do. The policies and specifications change from time to time, and such automated tools cannot hope to be both comprehensive and up-to-date.

As someone who has some familiarity with the OS packaging process, I would beg you not to make OS-specific packages without a good, current understanding of the OS packaging policy you're targeting. If that doesn't sound like fun, just concentrate on making your program great, standards-compliant, and responsive to bug reports — especially from OS package maintainers. That will make it much more attractive and give a much better change of having a good range of OS-specific packages.

Thanks for you long and thourough answer Ben! So your proposed course of action is 1) learn distutils + setup.py ecosystem 2) concentrate on application itself, not packaging 3) make some kind of fast-feedback system to achieve (2) I can see a conflict between (3) and (2) - since packaging is not under my control all feedback will be severely delayed, from users of my app. What is a good approach to minimize time from release to packaging? I agree in general with your remarks, it's just that fast feedback is one of the most important things to have for game (or any app for that matter).

...

-- \ “Technology is neither good nor bad; nor is it neutral.” | `\ —Melvin Kranzberg's First Law of Technology | _o__) | Ben Finney

_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig

-- twitter.com/olofb olofb.wordpress.com olofb.wordpress.com/tag/english

Ben Finney

4:01 a.m.

Olof Bjarnason writes:

...

So your proposed course of action is

1) learn distutils + setup.py ecosystem

Yes, this is essential. It's also, fortunately, not a very large topic URL:http://docs.python.org/distutils/. It is, unfortunately, rather flaky (you can read the archives of this forum to see some of the hair-pulling it causes), and it gets more complex in the non-core third-party extensions that have arisen to address some of the Distutils shortcomings (see e.g. Setuptools), but first things first: learn and use Distutils, the current standard distribution system for Python software.

...

2) concentrate on application itself, not packaging

Yes. With a good program, distributed with the whole work under widely-understood free software license terms (e.g. GNU GPL) and published on PyPI URL:http://pypi.python.org/pypi/ as an ‘sdist’, packagers will come to make OS-specific binary packages.

...

3) make some kind of fast-feedback system to achieve (2)

I can see a conflict between (3) and (2) - since packaging is not under my control all feedback will be severely delayed, from users of my app. What is a good approach to minimize time from release to packaging?

The early adopters of your software will be those who are not afraid of building it themselves from an ‘sdist’. That population will be where the OS-specific package maintainers will come from. So, be responsive to your early adopters, and set up a distributed version control system and bug tracking system (at e.g. Bitbucket or Launchpad you can have both in the same place). Those early adopters may well provide patches against your code (which is why having a public distributed VCS is important), and will want to be able to track their reported issues over time (which is why an organised bug tracking system is important), as the issues are exposed and dealt with. If you continue to make releases that incorporate those changes that make sense for distribution to all users, that seems the best fast feedback. I don't see a conflict between your focus on being the core developer of the actual work, and others's focus on the OS-specific issues that arise. With each party focussing their attention where their skills are, and with the appropriate workflow tools in place, it's about as rapid as mere human programmers can hope for. -- \ “All good things are cheap; all bad are very dear.” —Henry | `\ David Thoreau | _o__) | Ben Finney

Floris Bruynooghe

2:41 a.m.

On Fri, Sep 25, 2009 at 10:23:58AM +0200, Olof Bjarnason wrote:

...

I'm new at the mailing list. I write small games in Python/PyGame. I want to find a way to make a downloadable package/installer/script to put on my webpage, especially for Ubuntu users.

I've skimmed a couple of tutorials on how to generate .deb-files, but, wow, it's a whole new skill set to do that!

Does anyone have any hint on a more economic way of creating single-file distribution packages for Python+PyGame projects? Maybe some GUI-tool that automates the .deb file creation process, but targetting Python specifically and not C++.

If your code (including dependencies) only uses pure-python you could use the executable zipfile feature of Python 2.6 to simply ship an executable that only needs Python. $ cat > __main__.py print('hi there') ^D $ zip test.zip __main__.py adding: __main__.py (stored 0%) $ cat > hashbang.txt #!/usr/bin/env python3.0 ^D $ cat hashbang.txt test.zip > my_exec $ chmod +x my_exec $ ./my_exec hi there $ Obviously you'd have to put all your the packages and modules you depend on inside the zipfile. This sort of sounds like what you are looking for. It's not a replacement for a properly shipped/distributed application but does a good job if you just want to give your friends a small game to play. Regards Floris PS: My search-foo must be low today as I couldn't find any official documentation on this. Any pointers? -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org

Olof Bjarnason

2:46 a.m.

2009/9/25 Floris Bruynooghe :

...

On Fri, Sep 25, 2009 at 10:23:58AM +0200, Olof Bjarnason wrote:

...
I'm new at the mailing list. I write small games in Python/PyGame. I want to find a way to make a downloadable package/installer/script to put on my webpage, especially for Ubuntu users.

I've skimmed a couple of tutorials on how to generate .deb-files, but, wow, it's a whole new skill set to do that!

Does anyone have any hint on a more economic way of creating single-file distribution packages for Python+PyGame projects? Maybe some GUI-tool that automates the .deb file creation process, but targetting Python specifically and not C++.

If your code (including dependencies) only uses pure-python you could use the executable zipfile feature of Python 2.6 to simply ship an executable that only needs Python.

It's not only python, it's PyGame too.

...

$ cat > __main__.py print('hi there') ^D $ zip test.zip __main__.py adding: __main__.py (stored 0%) $ cat > hashbang.txt #!/usr/bin/env python3.0 ^D $ cat hashbang.txt test.zip > my_exec $ chmod +x my_exec $ ./my_exec hi there $

Obviously you'd have to put all your the packages and modules you depend on inside the zipfile.

This sort of sounds like what you are looking for. It's not a replacement for a properly shipped/distributed application but does a good job if you just want to give your friends a small game to play.

Regards Floris

PS: My search-foo must be low today as I couldn't find any official documentation on this. Any pointers?

-- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org

-- twitter.com/olofb olofb.wordpress.com olofb.wordpress.com/tag/english

Zooko Wilcox-O'Hearn

3:20 p.m.

On Friday,2009-09-25, at 2:23 , Olof Bjarnason wrote:

...

I've skimmed a couple of tutorials on how to generate .deb-files, but, wow, it's a whole new skill set to do that!

Have you tried stdeb? http://github.com/astraw/stdeb Check out the section entitled "Quickstart 1: Just tell me the fastest way to make a .deb". Regards, Zooko

Olof Bjarnason

26 Sep 26 Sep

1:14 a.m.

2009/9/26 Zooko Wilcox-O'Hearn :

...

On Friday,2009-09-25, at 2:23 , Olof Bjarnason wrote:

...
I've skimmed a couple of tutorials on how to generate .deb-files, but, wow, it's a whole new skill set to do that!

Have you tried stdeb?

http://github.com/astraw/stdeb

Check out the section entitled "Quickstart 1: Just tell me the fastest way to make a .deb".

This looks interesting! This seems to be the path to follow: 1. Learn setup.py+distutils 2. Fix my project to follow that convention 3. Upload project to pypi 4. Use stdeb to generate .deb

...

Regards,

Zooko

-- twitter.com/olofb olofb.wordpress.com olofb.wordpress.com/tag/english

Andrew Straw

7:43 a.m.

Olof Bjarnason wrote:

...

2009/9/26 Zooko Wilcox-O'Hearn :

...
On Friday,2009-09-25, at 2:23 , Olof Bjarnason wrote:

...
I've skimmed a couple of tutorials on how to generate .deb-files, but, wow, it's a whole new skill set to do that!

Have you tried stdeb?

http://github.com/astraw/stdeb

Check out the section entitled "Quickstart 1: Just tell me the fastest way to make a .deb".

This looks interesting!

This seems to be the path to follow:

1. Learn setup.py+distutils 2. Fix my project to follow that convention 3. Upload project to pypi

Strictly speaking, that step 3 is not necessary.

...

4. Use stdeb to generate .deb

-Andrew

Olof Bjarnason

8:51 a.m.

2009/9/26 Andrew Straw :

...

Olof Bjarnason wrote:

...
2009/9/26 Zooko Wilcox-O'Hearn :

...
On Friday,2009-09-25, at 2:23 , Olof Bjarnason wrote:

...
I've skimmed a couple of tutorials on how to generate .deb-files, but, wow, it's a whole new skill set to do that!

Have you tried stdeb?

http://github.com/astraw/stdeb

Check out the section entitled "Quickstart 1: Just tell me the fastest way to make a .deb".

This looks interesting!

This seems to be the path to follow:

1. Learn setup.py+distutils 2. Fix my project to follow that convention 3. Upload project to pypi

Strictly speaking, that step 3 is not necessary.

...
4. Use stdeb to generate .deb

OK thanks. I gather stdeb does handle .deb-package dependencies, like PyGame, right?

...

-Andrew

-- twitter.com/olofb olofb.wordpress.com olofb.wordpress.com/tag/english

Andrew Straw

1:42 p.m.

Olof Bjarnason wrote:

...

OK thanks. I gather stdeb does handle .deb-package dependencies, like PyGame, right?

Yes, you have to add them as a config option. See the "Depends" config option in "Customizing the produced Debian source package (config options)" in the README. -Andrew

5323

Age (days ago)

5324

Last active (days ago)

List overview

Download

10 comments

5 participants

participants (5)

Andrew Straw
Ben Finney
Floris Bruynooghe
Olof Bjarnason
Zooko Wilcox-O'Hearn

Distributing Python-programs to Ubuntu users

Floris Bruynooghe

Andrew Straw

Andrew Straw

tags

participants (5)