2009/9/25 Ben Finney <[email protected]>: > 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 <[email protected]> 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 - [email protected] > http://mail.python.org/mailman/listinfo/distutils-sig > -- twitter.com/olofb olofb.wordpress.com olofb.wordpress.com/tag/english _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
