[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Introducing Pygame Launcher alpha

On Oct 22, 2004, at 2:17, Sami Hangaslammi wrote:
On Fri, 22 Oct 2004 08:05:02 +0200, Jack Nutting <jn_list@rebisoft.com> wrote:
I think this seems like a very interesting idea, and I'd surely
consider distributing my games this way.  The only potential problem I
see is with library versioning.  For example, it seems that if I were
currently working with a prerelease pygame 1.7, then my pyg wouldn't
work with this;  conversely, whenever your pyglauncher goes over to
pygame 1.7, older pygame 1.6 pyg files won't work.  Or am I missing
something?

The .pygs aren't any more version dependant than your standard Python
files. So if Pygame 1.7 breaks backwards compatibility so that normal
python scripts programmed for 1.6 break, then 1.6 pygs will break too
if 1.7 is updated to the launcher.

I see it as one of the benefits of the launcher, that you will always
know what library versions your users will have, so you are able to
test your game using the same exact versions (by using the launcher).
It is one of my TODOs to include the launcher version in the .pyg
file, so the program can inform users when they need to upgrade to a
newer launcher. Generally, the Python extensions in question break
backwards compatibility very rarely, so it is only a problem if you
want to use the very latest features.

I think that as a common platform, the launcher will benefit the most
if the extension versions are locked into the latest versions when 1.0
final comes out. After that, the extension versions should be changed
only in major releases of the launcher, IMHO. This way the
compatilibity features of the launcher might make it a useful software
even for those who already have Python et al installed, so they don't
have to worry about library versions.
Most people solve these problems by just making self-contained packages for their applications.

I can only really see Pygame Launcher having maybe one and a half small advantages over self-contained packages:

- The user saves some disk space and bandwidth *if and only if* Pygame Launcher is popular amongst developers. Otherwise you're just making the user download two things (the launcher and your pyg) instead of just getting your application.

- A single pyg might work correctly across several platforms. You only need to offer one download link and it will support any platform that Pygame Launcher supports. However, in my experience, in order for the application to be well liked you'll still need to make some platform-specific accommodations. For example, Windows and Linux developers typically assume that they write code that requires more than one mouse button when that isn't always the case on a Mac. The high-level frameworks abstract this by making ctrl-click equivalent to a second mouse button (I don't remember if SDL inherits this or not), but in any case you should avoid doing that. When I ported Pathological to the Mac, I changed the UI slightly so that it worked perfectly fine with one mouse button and no metakeys (their two-button-requiring UI really wasn't fun to play when using my laptop's trackpad).

- Creating a pyg might be easier for some people to do than creating a self-contained application. It might be a better idea to just make py2exe smarter like py2app is on the Mac. In fact, I bet making a py2app application is just as easy, if not easier, than making a pyg distribution.

.. but it does have a bunch of downsides, for developers anyway. The largest of which being that the platform is inflexible. You're stuck with a subset of the standard library and specific versions of a couple useful packages. Anything other than that must be done in pure Python.

In any case, if a bunch of developers decide on using this, I'll make sure it works correctly on the Mac.. but it's not something I have a real use for myself... but then again, I've been working very recently on similar problems from the other end (making smarter packaging tools).

-bob