On, Mon Aug 21, 2006, Phil Hassey wrote: > > I am with Richard in planning for Pygame-ctypes becoming the trunk and > > future development on Pygame stopping at 1.8.x. Your expertise in > > Pygame would be invaluable in implementing the required optimisations in > > Pygame-ctypes, and I would not like to see the community forked. > > Why do all people think, that forks are bad? In my opinion this fork > would bring greater benefits to the pygame community. Both versions > can be developed for their very own needs and tweaks. The C version is > definitely suitable for environments with limited resources and > performance (e.g. embedded, older systems, etc.) while the ctype > overhead is not. > > 2. Linux distribution of my games. "Game X depends on pygame-X" > "Well, my distro only has support for pygame-Y" ... No profit in > that for me. Less linux users will play my games if they don't > work everywhere out of the box. (Non issue for win32 > distribution as I py2exe everything.)1 Well, now that's a _really_ critical problem. If the distribution does not ship with the wanted package, it is a problem of the distribution packagers, not yours, mine or of the possible pygame forks. > 3. Distributions in general will probably only support one. Again a distribution problem, not one of ours. Many software and forks are not supported out of the box by distributions, but some software relies on them (which is naturally not shipped with the distribution, too), so what? > 4. Major pygame libraries like pgu, ocempGUI, pygext, etc will > either have the pain of trying to make sure that they are pygame > and pygame-ctypes compatible, or they will have to choose one or > the other. Which is the problem of the respective developers, not pygame's. When X.org was forked from XFree86, tons of binaries (especially commercial ones) either needed to be dropped or rereleased with matching compatibility layers, because several distros simply dropped the XFree86 support and switched to X.org. Rude of them, isn't it? Talking as developer, I do not care about that. If the people want my software, they have to rely on what I force them to use (this is the default for _any_ software). So those who want to use the stuff, will a) either make it compatible (if not done by the author) or b) go ahead with its dependencies. As author of OcempGUI I do not see the point why _I_ have to maintain two versions of my software and/or provide compatibility. I decide, what I want the user to use. He can either stick with that or let it be. It's up to him. This definitely sounds ignorant, but it is also ignorant, that I force the user to use e.g. Python >2.3 and noone complains about missing compatibility to Python 2.2, 2.0, 1.5, ..., so where's the problem with that? if it does not fit the user's needs, he won't use it. > > Again, to reiterate my roadmap: > > 1. pygame continues as the lead in pygame, new features etc. > 2. pygame-ctypes follows step-by-step pygame and makes sure to be 100% compatible on its python interface > 3. pygame-ctypes is made to work on all platforms supported by pygame ATM > 4. pygame-ctypes should NOT use any c code (no using c, pyrex, swig, etc.) > 5. when pypy makes python fast, and it makes pygame-ctypes as fast > (or faster) than pygame, we switch to using pypy and pygame-ctypes, > and drop pygame and python. And give all those people who wrote e.g. C library extensions using the old pygame a kick in the butt. This will not be compliant with 4 ;-). Whoa, I am just getting into a "bash-anything" mood, so do not take anything said too serious :-). Regards Marcus
Attachment:
pgp37yFuKSXhy.pgp
Description: PGP signature