How large is the TMX library? Are we talking about just a few kb of code? In my opinion, part of the headache with new coders is learning to deal with the install of multiple libraries. I'd rather have a few extra k of install than ask new coders _again_ to match their OS, the version of python, and the version of Pygame they are on.
pip-install doesn't seem to work yet with Pygame, which would make it easier to manage. I'd love it if that worked for Linux, Mac, and Windows across the major Pygame distributions. Paul Vincent Craven On Fri, Oct 3, 2014 at 1:53 PM, Leif Theden <leif.the...@gmail.com> wrote: > 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? > > I don't see it as a rush. It may *feel* like a rush when compared to the > pygame release schedule. > > > On ven, 2014-10-03 at 11:15 +0200, Santiago Romero wrote: > > A.- Sometimes there are lots of available options and it's confusing > > knowing which one is the "most stable" or "most used" or the one where > > you will have more support in case you need help (an > > "default/official" library). > > I think that in general, the pygame project has done well by keeping a > consistent API and being stable across releases. The TMX map format is a > simple XML format and so far in the 2 years or so I've maintained PyTMX, > has not introduced and changes that would break existing maps. In that > respect, it would be a safe assumption that the format would not need much > maintenance, and wouldn't be a big burden to keep in pygame. I want to > note that PyTMX isn't a game engine or framework, it just exposes the data > and tile images. > > > > Agreed, this can be done with a semi-official list of libraries. It > > should aim to have only one project listed for each thing. Any time more > > than one library is listed it should provide a clear description > > answering the question "Why (or when) should I use project Y over > > project X?". > > In any case, having a easy-to-find page on the site with a list of > 'official unofficial modules' :) would be a great help. I can understand > why some people would rather keep things like map loading functions out of > the core, but new users of pygame need to know that the tools they want to > use are supported. Included in the core would be nice, but treating a few > great unofficial "works with pygame" modules would also encourage people to > pick up pygame. > > To that list I would add pymunk, since you can still do things the "pygame > way". > > > On Fri, Oct 3, 2014 at 5:27 AM, Sam Bull <sam.hack...@sent.com> wrote: > >> On ven, 2014-10-03 at 11:15 +0200, Santiago Romero wrote: >> > A.- Sometimes there are lots of available options and it's confusing >> > knowing which one is the "most stable" or "most used" or the one where >> > you will have more support in case you need help (an >> > "default/official" library). >> >> Agreed, this can be done with a semi-official list of libraries. It >> should aim to have only one project listed for each thing. Any time more >> than one library is listed it should provide a clear description >> answering the question "Why (or when) should I use project Y over >> project X?". >> >> >
