On ven, 2014-10-03 at 12:24 +0530, diliup gabadamudalige wrote: > Why can't all these add on's be separate modules or packages and leave > Pygame to run it's own natural course as it has done in the past? Why > this rush to include these libraries INTO Pygame?
Read the proposal you just replied to. It suggested putting these addons in a pygame-extras package, so they are somewhat official but still separate from actual Pygame. This seems acceptable to me, though it may be better to be able to download each module/library individually as it's likely only a couple of libraries are useful for any one project. I think adding a 'Pygame tools & libraries' or similar subheading to the download page that can then have a semi-official list of libraries/modules to be used with Pygame would be the best idea. I think the main issue is for a new user of Pygame to discover these other tools and libraries, so they don't need to reinvent everything when there are already better implemented and tested libraries available. > On Fri, Oct 3, 2014 at 11:41 AM, Santiago Romero <srom...@sromero.org> > wrote: > > Maybe something like pygame-extras-vX.X (including TMX support > and other possible interesting features that other high-level > libraries have) that matches exactly (and is totally > compatible) the pygame-vX.X would be fine. > > > This way people that only wants the "core libraries" could > just install pygame. And people that wants the "extras" can > install the other package among with the core. > > > That would be different from packing it as a "pygame 3rd party > library" (like those that you can download from pygame.org) > because it will appear in the main download page and they will > be packages in the APT/YUM repositories of the distros, > meaning that they are the "default libraries" for diverse > tasks (TMX maps, scenes, X feature, Y support, Z, etc)...
signature.asc
Description: This is a digitally signed message part
