making apps, making webs.

This article is part 2 in a series about improving python game distribution. In part one I suggested that python games should be packaged as python packages . Part three is about where the code & data things are . More discussion is happening on the pygame mailing list. Making apps for platforms more easily. Android, windows, mac installers, pip wheels, snappy... the list of platforms goes on. All that is quite time consuming to setup. So how do we make this easier? Have a standard package layout, and build tools which work on that layout. The Python Packaging Authority has put out a git repo with a basic python package. I think we should create one based on that and use it for the 'skellington' that pyweek uses. Skellington is 'base code', or boilerplate code used in the pyweek competitions. It makes doing things like creating windows .exe files, and such easy. Because it does all of the work to configure things correctly. If we have a standard package

This is a statement of intent similar to what I wrote to the pygame mailing list some weeks ago. That I think the python game community should promote packaging their games as python packages. When I wrote to the mailing list, not everyone was convinced, and some people had other ideas. So I'm going incorporate their feedback, and to try to be more detailed on the full plan of where I think we should go, what benefits this provides the python community as a whole, and the benefits it provides game developers. This is the first in a series of articles about making python game distribution better. “ the python game community should use python packages ” With all the great work from lots of people pygame is often easily installable via pip - the standard python packaging system. We still have some issues, but it works quite well on major platforms. See " How we cobbled together a free Spectacularly Adequate Build Page. " for more details on how we package pygame

pyweek registration is open. For the biannual game jam. http://www.pyweek.org/23/ Which means you can join, and put your self in a team, or join up as a solo entrant. Spend a week(part time) finishing a game using python. Sunday 19th of February to Sunday 26th of February. It is inspired by the ludumdare 48h comps, but people only use python, it is a week long, and there can be teams. Over 100 entrants joined in on the fun previous competitions. Enter to have a chance to prototype your next game, or see if working in a team will work on a small project. Or just have a break, to get your creative juices going, and to feel all of the energy of 100+ people simultaneously feeding off each others creations. http://www.pyweek.org/23/ It's also a great way to learn, and have fun with python. It's possibly the best way to improve your programming skills, and game making skills there is. Timetable Friday 2017/01/20 Pre-registration underway Sunday 2017/0

This is a story of how we cobbled together a collection of free build bot apps for pygame - the python game development library. So the internet could build our software for us. Hey, many Free and Open Source projects might find this useful too... I thought... so here is the story. Continuous integration is great. It's even greater when you have dozens of platforms, and many versions of a python interpreter you need to have things run on. It means your python 2 contributors on linux can see that their change broke an OS X build on python 3. Every change you make things get built for all the different platforms, and tests are run, installers are built, and packages are made. In 2008 the pygame project had the great fortune for 'thorbrian' and some other contributors to set up a build page for Windows, and Mac. Two platforms which had sort of tricky python build setups not so commonly understood in the FOSS world. " The Spectacularly Adequate Automated Pygame Bui