Re: [pygame] pygame with SDL2 proposal

I think this is a really good thing to think through.

The issues you bring up hinge on one thing (compatibility concerns). So far the unit tests pass. From my investigations, I haven't been able to find any theoretical reasons why it can't be compatible for 99% of things using pygame.

The stronger evidence of tests passing, and no concrete theoretical reasons presented on why it can't be compatible suggests to me that it can be done. As the patches currently exist, and have for some time, gives me a reason to think those fears about OS packagers doing strange things are unfounded. As they upgrade SDL versions at different times, I think we should still be ok if things are compatible.

By not aiming for compatibility we guarantee there won't be. Having a compatible pygame API lets us do that, and still release to places where SDL2 doesn't exist yet. If considering the API is compatible as I hope, then I don't see a problem with people who require SDL2 features seeing if they are running on an SDL2 pygame.

A pygame 2.0 would be released under the pygame package name, with SDL 2 as default, with a pygame compatible API. Until we get to that point pygame 1.10.0+ will exist, but patches and conditional compilation will be available for SDL2. (as they exist right now, but made easier to select). Old modules like cdrom, and overlay will be marked as depreciated.

By using new pygame APIs for differences between SDL1 and SDL2 we allow the old apps to continue working. So there should be no sudden break the world transition.

If an app really isn't compatible with a newer pygame for some reason (unlikely IMHO), then it's still possible for an older version to be bundled with pip, conda, and many virtual envs. Things like apt, could do like they did with SDL1, and python2 and python3. That is, making pygame1 into a pygame1-sdl1 package, which perhaps gets installed as pygame1. Then the rare cases of old uncompatible apps, which have not been updated themselves are covered. But I honestly don't think that will happen.

On Mon, Mar 20, 2017 at 11:15 AM, Thomas Kluyver <takowl@xxxxxxxxx> wrote:

Having a codebase compatible with both versions of SDL sounds sensible, but having spent a day considering it, I suspect it would be a mistake.

Compatibility is never going to be perfect, so in practice I expect that a lot of games will require "pygame 1.10 compiled with SDL 2" or "...with SDL 1.2", according to what the developer tested it with. The packaging systems I'm familiar with are not able to express a dependency like this. So it would be useful if the name (e.g. pygame2) or version (e.g. pygame version 2.0) of the package encoded that it was based on SDL 2.

To frame this another way: for most people there will be a sudden transition when the pre-compiled packages they use switch to building with SDL 2. If pygame makes releases that are compatible with both SDL versions, the packages from PyPI, conda, apt, homebrew and so on may make that transition at different version numbers, generating confusion. If pygame 2.0 simply switches to SDL 2, the switch is coordinated, so the version number is a reliable indicator of what you're getting.

So if we do turn the pygame codebase into an SDL 2 wrapper, rather than adopting/recommending one of the existing wrappers, I would strongly suggest that we a) make a clean switch, not attempting to support both, and b) use a new major version number, or even a new package name, to clearly distinguish it.

Thomas