on my system it is 44k without docs or tests. On Sat, Oct 4, 2014 at 11:08 AM, Paul Vincent Craven <p...@cravenfamily.com> wrote:
> 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?". >>> >>> >> >
