Using a common file layout lets us create distributables more easily. Part 2.

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 layout, it is easier for us to build tools to share. Distribution and packaging tools.

The problem with creating packages for many platforms is that you need that platform to create the packages for it. So if a developer is on windows, they find it difficult to package an app for mac and linux.

Free build bots will allow people to have packages created for them.

If their games are in a standard layout, then we can even make a central repository that creates packages for other games automatically (without them having to setup the buildbot accounts themselves).
Travisci - linux, mac, and android.
Appveyor - windows.

Of course people can do all this themselves, using scripts we share. But a centralised build bot will mean that only needs to be setup once for everyone.

What needs to be made?

  1. A fork of pypa sampleproject, merged with skellington.
  2. A library for creating .exe, .dmg etc using different platform packaging tools.
  3. Configuration for the buildbots for different platforms (.travis.yml etc).
  4. Using the sampleproject we make a cookiecutter template from the sampleproject.
Where? Probably on the pygame github organisation.

What will people have to do to build their project?

 These are approximately the steps people will need to do in order to package their app.
  • python3.6 -m venv anenv
  • . ./anenv/bin/activate
  • pip install cookiecutter pygame
  • ...generate base code... cookiecutter pygame/skellington mynewgame
  • ... fill in meta data, like game name, url etc...
  • ...upload project to github...
  • ...create travisci and appveyor accounts...
  • ...enable repo for travisci and appveyor ...
Some of these steps can be automated, and some can be removed.

Continue to Part three where the code & data things are.



Popular posts from this blog

Is PostgreSQL good enough?

pygame on pypy usable

Experiments with new low latency PyPy garbage collector in a thread.