[pygame] PyGame Website Rewrite
jug
Even if it was not selected as a project for GSoC, I would like to do
the pygame website rewrite.
Like the other applicants, I'd do that with Django. Now that there can
not only be one student/participant,
it would be cool to work together and combine forces.
Since I applied for GSoC, I've already made a small concept. Merging
multiple implementing-/design ideas
may become difficult, but before I go into detail just say me if you are
interested.
Regards
Jug
orcun avsar
el lauwer
Tobad that the rewrite of the pygame website wasn't accepted as a GSUC
project. But I think it would be a good idea to rewrite the site
anyway, since the current site is a bit outdated. Maybe someone should
put up a project page (wiki?).
Here are some random ideas:
* I really like the django site, since the code is available under
GPL we can base our site on that consept.
code: http://code.djangoproject.com/browser/djangoproject.com
* I think Trac would be usefull replacement for the current wiki and
viewcvs, maybe in combination with git?
http://nanosleep.org/proj/trac-git-plugin/
* A better separation between documentation, news, projects and
development.
Grtz
Ian Mallett
Certainly revisions are in order. As a personal opinion, I like the general layout/theme as is--but things like the documentation are out-of-date and faulty (for example, http://www.pygame.org/docs/ does not link to pygame.color, among other modules). A few projects have been in the "spotlight" on the main page for months, etc.
Ian
orcun avsar
for example, http://www.pygame.org/docs/ does not link to pygame.color, among other modules
Ian
Ian Mallett
Lenard Lindstrom
be nice, it has become a lesser priority since the documentation is now
bundled with the Pygame installer. For Python 1.9 just go into
site-packages/pygame/docs to find them.
Lenard
Devon Scott-Tunkin
I'd like to help on the graphics side, the current site kind of looks like the python threw up all over the place.
--- On Tue, 4/21/09, jug <j...@fantasymail.de> wrote:
pymike
- pymike
jug
to organize the development process, I've set up a SVN-repo and a small
Trac at http://pygameweb.no-ip.org/trac/
You'll find there a first concept and you can take part in developing
it by adding your ideas. Some of the point are completely to work out,
so just have a look. If you have a complete concept for one of the
points (eg the design) create a new wiki page and add a link.
If you would like to participate in developing, add yourself to the list
on the start page and provide some information like I did.
I've done the setup on the quick so if there are any problems with Trac
or you need more rights, please email me.
Regards,
Jug
René Dudfield
very awesome of you to go ahead with this...
I read through your website... and it's got some good ideas...
It'll be cool if we can make pygame one of the best sites around in the python scene again... the current one is from around 2005... and has been really good so far.
Rewriting the current functionality in python first could be a good way to go. Once the current site is replicated, then move on to other stuff.
All the old stuff needs to be written at some point... because we need to keep all the old urls around (including feeds). Also it's easier for people to work towards something that exists, rather than working towards a new design.
Another benefit of remaking the existing website will be to understand the features of the current site.
Remember, the main focus of the website should be peoples projects... especially updated projects. With all the other stuff coming after that.
First steps are to agree on a way forward... but if we go with remaking the existing site... we could follow this path:
- prepare html/php/sql from old site.
- get old site running outside of the main pygame.org so people can test it easily.
- decide on which tools we are to use. The main ones from people interested seem to be a django, or a cherrypy based site.
- start writing the models for the various tables, and data types in existing site (eg, project, user, wiki page, etc).
- collect a list of existing urls.
- collect a list of existing functionality.
- collect a list of html/php pages to convert to templates.
- start working on list of functionality, and templates until it is complete.
- put site up for people to test on a test domain.... eg test.pygame.org
- replace existing website on pygame.org, and make sure it works ok.
- END. then can work on adding new stuff.
We can even make some basic functional tests to start with based on the output of existing urls. eg, grab the html from a wiki page from the existing site, and then compare it to our new website.
Also, is it possible to do this at google code instead?
http://code.google.com/p/pygame/
What does everyone think of this?
cheers,
jug
Analyzing the current page in detail is a good aspect to exchange
the site without any problems. Do we need to run and modify the current
page or is enough to read the code? Then you could send it to me and I'll
upload it to the page (I think we don't need it in SVN, do we?).
Sure, we could do that at google code but first I think, Tracs better
(and looks
nicer) for developing with the community and then we could run the new
website
from SVM there so everyone can always have a look at the latest version
and test it.
And you normally don't get an confirmation email. Just register and login.
Regards
Jug
m...@sysfault.org
> hi,
>
> very awesome of you to go ahead with this...
>
> I read through your website... and it's got some good ideas...
>
> It'll be cool if we can make pygame one of the best sites around in the
> python scene again... the current one is from around 2005... and has been
> really good so far.
Well, the colours started to hit some nerves for me, so it might be better
to go with some pastel colour palette for the new one :-).
> Rewriting the current functionality in python first could be a good way to
> go. Once the current site is replicated, then move on to other stuff.
>
> All the old stuff needs to be written at some point... because we need to
> keep all the old urls around (including feeds). Also it's easier for people
Is there a way to have some easy to manage URL rewriting/forwarding in
Django? That way we could let existing URLS resolve to the new stuff (e.g.
place the currently static html sites into the DB and link to them).
> to work towards something that exists, rather than working towards a new
> design.
A new design is necessary in my opinion. Colours, overall style, etc.
The functionality though needs to stay the same (with improvements all over
the place).
> Remember, the main focus of the website should be peoples projects...
> especially updated projects. With all the other stuff coming after that.
Seconded.
>
> First steps are to agree on a way forward... but if we go with remaking the
> existing site... we could follow this path:
>
> - prepare html/php/sql from old site.
> - get old site running outside of the main pygame.org so people can test it
> easily.
The current one is already around and was widely tested. Or do I miss
something here?
> - decide on which tools we are to use. The main ones from people interested
> seem to be a django, or a cherrypy based site.
> - start writing the models for the various tables, and data types in
> existing site (eg, project, user, wiki page, etc).
> - collect a list of existing urls.
> - collect a list of existing functionality.
> - collect a list of html/php pages to convert to templates.
> - start working on list of functionality, and templates until it is
> complete.
Sounds good to me. Though I'd go with the existing functionality first. The
existing URLs and such are things to be considered for a final migration.
Thus I would move this to the end:
- put site up for people to test on a test domain.... eg test.pygame.org
- work out migration plan:
- migrate projects and static content
- add functionality for eixsting URL handling
- replace existing website on pygame.org, and make sure it works ok.
- END. then can work on adding new stuff.
Otherwise it might easily happen to limit the new system in some areas due to
the existing structure.
Working out the migration can happen in parallel to the test phase. Letting
people test is nothing, which should keep you on a 24/7 work load, so while
anyone plays around with it, you can work on the necessary conversion system.
> Also, is it possible to do this at google code instead?
> http://code.google.com/p/pygame/
Sounds reasonable - google already has the whole functionality for the
project,
Julian currently hosts privately. It might be good to use google's wiki there
and a seperate website SVN branch. Especially since the final system could be
adopted by other community-driven projects.
Regards
Marcus
Peter Gebauer
The two main priorities, imho, would be
1) documentation up to date with code
2) a wiki for additional documentation, examples, build instructions
on various platforms, etc.
The project content could be easily transfered to wiki too. It might not
be better than a full database interface, but it's sufficient and easy
to maintain.
Also, there are already api doc generators for Python and good wiki's, so
no extra code would be written, only a build script for automating the process.
As a bonus, if we can generate API docs for specific versions that would be a
huge help.
/Peter
jug
Most of your points are already listed there. Add new ones so
we get an overview.
Jug
René Dudfield
Hi,
Analyzing the current page in detail is a good aspect to exchange
the site without any problems. Do we need to run and modify the current
page or is enough to read the code? Then you could send it to me and I'll
upload it to the page (I think we don't need it in SVN, do we?).
yeah, you're right. I think reading the current code is likely good enough.
Phil sent me a tar.gz with the website code... I have to finish going through it to make sure there's no passwords, or peoples private information in there. Then I'll upload it soonest so you can have a look through it.
Marcus, when I'm done looking through it, can I send it to you to have a quick double check for private info?
I'll have to do the same with the database data... get rid of email addresses etc before upload.
Sure, we could do that at google code but first I think, Tracs better (and looks
nicer) for developing with the community and then we could run the new website
from SVM there so everyone can always have a look at the latest version and test it.
And you normally don't get an confirmation email. Just register and login.
Regards
Jug
Sorry, I think we're going to have to go with the google code website. Because it's got all the nice account management, which a lot of people have accounts with already... and it kind of seems safer hosted there. As a bonus though, you won't need to administer it.
I have added these people to the http://code.google.com/p/pygame/
jug, pymike, marcus, nicholas, orcun, ian
Just with your google account email address on this mailing list... if you want to use another email address please send it over.
If anyone else wants to help with the website, please send me your google account email address off the mailing list to my email address directly (you can use non-google emails for your google account).
cheers,
René Dudfield
René Dudfield <ren...@gmail.com>:Well, the colours started to hit some nerves for me, so it might be better
hi,
very awesome of you to go ahead with this...
I read through your website... and it's got some good ideas...
It'll be cool if we can make pygame one of the best sites around in the
python scene again... the current one is from around 2005... and has been
really good so far.
to go with some pastel colour palette for the new one :-).
yeah, perhaps. We should probably have the graphical design as a separate step. So we can choose the best design made available.
Is there a way to have some easy to manage URL rewriting/forwarding in
Rewriting the current functionality in python first could be a good way to
go. Once the current site is replicated, then move on to other stuff.
All the old stuff needs to be written at some point... because we need to
keep all the old urls around (including feeds). Also it's easier for people
Django? That way we could let existing URLS resolve to the new stuff (e.g.
place the currently static html sites into the DB and link to them).
Almost all web toolkits have decent url schemes, and rewriters. It can also be done at the apache, and wsgi levels too. The current website has a pretty good system... where it uses a database of rewrite rules editable through the web in the management system... but we can easily use mod_rewrite or whatever we need.
I don't think we have agreed on Django specifically yet. At least pymike, and I have suggested using cherrypy. Also I know Nicholas has made the last few websites he worked on with cherrypy.
So we should decide this based on what the contributors to the website feel is best, and also the people who will maintain it.
A new design is necessary in my opinion. Colours, overall style, etc.
to work towards something that exists, rather than working towards a new
design.
The functionality though needs to stay the same (with improvements all over
the place).
Sure, but that can happen after the current one is updated. It's much easier to make design as a separate stage.
So when reimplementing it we have the current website as a reference. With a new graphical design coming afterwards(or designed separately in parallel).
The current one is already around and was widely tested. Or do I miss
First steps are to agree on a way forward... but if we go with remaking the
existing site... we could follow this path:
- prepare html/php/sql from old site.
- get old site running outside of the main pygame.org so people can test it
easily.
something here?
Yeah, that can be used for lots of things... but not all. So as to test things without messing up the main website... eg adding projects, wiki pages, news etc. Maybe we don't really need to do this... and can just look at the code mostly.
Sounds good to me. Though I'd go with the existing functionality first. The
- decide on which tools we are to use. The main ones from people interested
seem to be a django, or a cherrypy based site.
- start writing the models for the various tables, and data types in
existing site (eg, project, user, wiki page, etc).
- collect a list of existing urls.
- collect a list of existing functionality.
- collect a list of html/php pages to convert to templates.
- start working on list of functionality, and templates until it is
complete.
existing URLs and such are things to be considered for a final migration.
Thus I would move this to the end: - work out migration plan:
- migrate projects and static content
- add functionality for eixsting URL handlingOtherwise it might easily happen to limit the new system in some areas due to
- replace existing website on pygame.org, and make sure it works ok.
- END. then can work on adding new stuff.
the existing structure.
Working out the migration can happen in parallel to the test phase. Letting
people test is nothing, which should keep you on a 24/7 work load, so while
anyone plays around with it, you can work on the necessary conversion system.
Yeah good point.
We will need to make sure the existing data can be put into the new website at some point.
It can be easy to take the existing database and just use that. This is quite easy to do with things like sqlalchemy and the like.
So to decide which way we go, we should study the database structure to see if it is ok.
Migrating the data is probably easiest if we use the existing database directly.
The wiki code is mostly html, so isn't that hard to convert.
Sounds reasonable - google already has the whole functionality for the project,
Julian currently hosts privately. It might be good to use google's wiki there
and a seperate website SVN branch. Especially since the final system could be
adopted by other community-driven projects.
Also lots of people already have google accounts on there, and it's not hosted on someones personal server.
Keeping it separate from the main pygame svn makes sense, since it's probably going to be a separate group of people, and also it's fairly easy to allow access to it.
Lenard Lindstrom
among several options then track the choice with a cookie.
Marcus von Appen
> On Fri, Apr 24, 2009 at 10:06 PM, <m...@sysfault.org> wrote:
>
> > René Dudfield <ren...@gmail.com>:
[...]
> >>
> >> All the old stuff needs to be written at some point... because we need to
> >> keep all the old urls around (including feeds). Also it's easier for
> >> people
> >>
> >
> > Is there a way to have some easy to manage URL rewriting/forwarding in
> > Django? That way we could let existing URLS resolve to the new stuff (e.g.
> > place the currently static html sites into the DB and link to them).
> >
>
> Almost all web toolkits have decent url schemes, and rewriters. It can also
> be done at the apache, and wsgi levels too. The current website has a
> pretty good system... where it uses a database of rewrite rules editable
> through the web in the management system... but we can easily use
> mod_rewrite or whatever we need.
>
>
> I don't think we have agreed on Django specifically yet. At least pymike,
> and I have suggested using cherrypy. Also I know Nicholas has made the last
> few websites he worked on with cherrypy.
>
> So we should decide this based on what the contributors to the website feel
> is best, and also the people who will maintain it.
I do not know anything about cherrypy, so here're some relevant
questions for both frameworks:
* How good is the integration of a wiki solution and maybe bug tracking
system without implementing it ourselves?
* How good is the integration of other components, which might be
necessary in the future?
* How much effort has to be put into it to add new features? Is it just
about adding/enabling a component or writing a whole bunch of code?
* What is the key difference between cherrypy (denoted as HTTP
framework) and Django (web framework)?
> It can be easy to take the existing database and just use that. This is
> quite easy to do with things like sqlalchemy and the like.
Absolutely no, I'd say. Did you put a look at its contents recently? ;-)
It'd be better to go with a new, clean database (and structure) and
write a set of SQL scripts to migrate the necessary data instead of
taking over anything.
Regards
Marcus
Nicholas Dudfield
> I do not know anything about cherrypy, so here're some relevant
> questions for both frameworks:
>
> * How good is the integration of a wiki solution and maybe bug tracking
> system without implementing it ourselves?
> * How good is the integration of other components, which might be
> necessary in the future?
> * How much effort has to be put into it to add new features? Is it just
> about adding/enabling a component or writing a whole bunch of code?
> * What is the key difference between cherrypy (denoted as HTTP
> framework) and Django (web framework)?
>
>
I have a little bit of experience with CherryPy and a tiny tiny bit of
experience with Django. Here is my 2.0 cents.
A while back I read a considerable amount about python frameworks before
choosing CherryPy
I say I chose CherryPy but that wasn't really the case. That choice was
made for
me. I did however choose further components to extend CherryPy with after
becoming frustrated with `raw` CherryPy and a `raw` DB2 api.
Making pages by concatenating strings is horrible and very resistant to
change.
You really want a templating system of some sort where you can integrate
designers changes nicely or have them do it themselves (concurrently)
You also want to be able to apply any special features your editor has for
editing html. Even PHP is better in this respect than `raw` CherryPy for
anything beyond a `Hello World` toy site.
Enter overwhelming array of choices. Then you have to find a way of
integrating
the templating system with CherryPy.
You'll find you want an ORM/query builder soon enough as writing your
own (again
using string building, you just want a small simple one) proves to be
distracting. Any time you want a feature requiring something beyond your
home-
baked lib you have to code something up and write tests for it.
Form handling? Do you want to write a form validation library? No? Spend
some
time searching for a good one *with a future*. Pagination? Email? I
literally
copy/pasted then modified the code from Django for the latter two.
In short, you end up writing an ad-hoc glue framework on top of
CherryPy. With
just one person working on it, you can get away without writing a heap
of tests
and documentation. With multiple people working on it you'd really need
to to
make sure everyone is on the same page.
Choosing CherryPy won't just be a matter of choosing it and running with it,
it'll also be a matter of choosing more components, how to integrate
them and
documenting it.
An advantage of doing it this way, not to be understated, is that you'll
learn
how to use those components individually and can apply them elsewhere.
From what I have read, each of the components in the Django stack have
superior
respective stand alone alternatives.
eg Django ORM is almost univerally agreed upon to be inferior to SQLAlchemy
Peronally I have used this stack for a few sites:
Request/Response/Server: CherryPy
ORM + Query Generator: SQLAlchemy
Form Handling: FormEncode
Templating: Genshi
Image Manipulation: PIL
If I needed to learn TurboGears 2 or Pylons for some reason then I'd already
know many of the pieces. SQLAlchemy, FormEncode, Genshi.
If I need to use database access for anything then SQLAlchemy is very
useful.
You can introspect existing databases easily and then just define the
relations
with a few lines of code. ( sqlalchemy.ext.sqlsoup ) If you define your
schema
in python then you can automatically build the tables to whatever
database you
like. SQLLite is useful for in memory test databases.
If I wanted to for some reason create dynamic and perfectly valid xhtml
based
documents( say for converting to pdf format with Prince XML) then Genshi
would
be hanging at my toolbelt. If I want to make a TRAC plugin I know how to
use its
templating language. (The main TRAC developer also designed Genshi )
CherryPy itself has a Tool system for integrating third party components
and for
abstracting code into reusable `filters`. Builtin Tools include unicode
codecs,
gzip encoding, json encoding, header modifiers and the like. It has
quite a nice
configuration framework supporting multiple deployment environments and
allows
you to target filters right down to the exact page handler. It is a great
foundation to build upon with many points of extensibility. Pure WSGI (which
CherryPy fully supports) is less granular as far as `middleware`.
However you *will* end up having to create a framework, whether it be
consciously written or it just evolves naturally from factoring out
duplicate
code. Needless to say, the first attempts will be pretty horrible. This,
on top
of writing the actual site.
The potential advantage to Django is that you are walking a well
travelled road
and it is well documented. And as it's a full stack framework all the
documentation is in one place, likewise with the `community`.
The #django irc channel almost rivals #python in terms of numbers. It is not
uncommon to see 600 people. In contrast #cherrypy will, anecdotally, have on
average 35 people.
Taking a *simplified* look at the python web world (leaving aside the Zope)
there is basically Django and the others. The others are basically split
into
the CherryPy camp and the `pure` WSGI camp. The WSGI camp which includes
Pylons
and Turbogears, the two biggest players behind Django, outnumbers
CherryPy in
terms of users.
If you don't know what WSGI is: http://lmgtfy.com/?q=wsgi+python
See http://www.cherrypy.org/wiki/CherryPyAndPaste for CherryPy's head
architects
comparison between CherryPy and Paste. Paste has most of the mindshare
of the
WSGI camp. Obviously he is biased but you can see where he is coming from.
This was written around the time the TurboGears community was deciding
to base
their framework no longer on CherryPy (version 2) but instead on
Paste/Pylons.
Oh and Paste has since started morphing into WebOb. Things change a lot...
CherryPy 3 is quite a different beast to its previous version and apparently
addresses a lot of the problems the TurboGears users had. An example of how
having many users drives forward development.
CherryPy is IMO (salt nugget: never actually *really* delved into other
frameworks) a superior more flexible technology but it is in the minority in
terms of userbase so the core has less bug finders and contributors. It also
means less people to help with potential problems. Less books written
and being
written about it. Less HOWTOs. Less mailing list subscribers. You will
be `using
the source` quite often.
FWIW Here is a rundown of people in irc channels at this point in time.
Python at large:
#python 683
Django School:
#django: 552
#pinax: 56
WSGI School:
#pylons: 102 (Mako templates irc)
#turbogears: 53
#pythonpaste: 21
Independents:
#cherrypy: 38
#sqlalchemy: 88
#python-genshi 15
Probably you'll have more potential contributors/maintainers using
Django. You
get a lot of guidance and free documentation with Django. Lots of Django
`apps`.
Things like finding editor support (Syntax highlighting / Code Snippets) for
Django templates I'd imagine would be very easy.
There is also an interesting project based upon Django pulling together
a heap
of reusable django `apps` called Pinax. See http://pinaxproject.com/ No
idea how
well it really works though going by the nubmers in the irc channel it is
gaining some traction. I remember watching a recorded presentation on it on
google video at some point and thinking it sounded pretty nifty.
After all is said, it looks like it is going to be a lot of work redoing the
site.
If most of the people that are motivated to do the work already have
experience
with Django I think it would just be more work for all involved using a
custom
CherryPy stack.
Contributors would have to follow the evolving `framework`. They'd have
to spend
time documenting it if they wanted to make it easy for more people to
contribute. They'd likely waste time arguing over the best ways of doing
things
and which components to use. Would it ever get done? Or would everyone
just get
sick of it?
For an opensource project with potentially quite a few people working on
it (The
more the better right?) then I'd say Django would be a good fit due to the
`free` unified documentation and resources surrounding it and the fact that
every one is on the same page.
Having never *really* used django but having read peoples criticisms the
only
hesitation I'd have in using Django is that it may not be flexible
enough to do
exactly what people want it do.
I can't see anything on the existing page that wouldn't fit inside Django's
*claimed* paramaters of operation though. The site isn't likely to need
database
sharding?
I have only done a few fairly simple sites with CherryPy and never got past
setting up the auto-admin with an old version of Django (0.96 svn).
Having said that I'd imagine if you worked within Djangos parameters (?)
you'd
have a nice site up and running quicker than using CherryPy and have a
larger
pool of potential contributors/maintainers.
For personal projects where you want total control I'd learn CherryPy
(and other peripherals)
for reasons mentioned above. It is a very flexible base to build upon.
It's a shame there
isn't more people using it as there would be more off the shelf components.
It would probably pay to actually hear from someone who has used both to
build
real sites and not just toy ones.
René Dudfield
very detailed emails from Marcus and Nicholas...
a few related points below.
I'd be interested in knowing what jug, and orcun think of using Django? Also what they think of a cherrypy based stack?
Also, what are the preferences of Lenard, Devon, pymike, and anyone else who is interested in contributing? Please state the level of commitment you're willing to make, and also which option(s) you'd be happy using.
- The main author of cherrypy(Robert Brewer) said he'd help us with any major issues we had, and so did some other cherrypy mailing list people. The cherrypy mailing list is also more active than the pygame one, so I'm sure we won't have any issues with docs or help.
- documentation is extensive for cherrypy(it's a 10 year old project, in it's third generation).
- we would have to choose a stack. The stack Nicholas mentioned seems pretty common, cherrypy + sqlalchemy + genshi + formencode/formalchemy + pygame of course for imaging... and joysick control of the website. So that is the stack we would be chosing.
- cherrypy code seems cleaner... as it's just python objects.
class MySite(object):
def index(self):
return "hello world!"
def news(self, id=None):
if id is None:
return main_news()
else:
return specific_news(id)
index.exposed = True
news.exposed = True
This creates these urls by default:
/
/index
/news
/news/10
/news?id=10
- cherrypy has less code compared to django, and is changing less.
- django is usually run using apache modpython or mod_wsgi, or even with cherrypy(or other wsgi server). They don't recommend using the bundled django webserver. Whereas cherrypy is considered one of, if not the best python web servers. With cherrypy you use the same webserver for development, and for production.
- you can run cherrypy inside a pygame application. Cherrypy doesn't control the main loop if you don't want it to.
- there are more wsgi components than there are pinax apps. Also pinax apps should theoretically be able to play with wsgi. I'm pretty sure you can use django apps as wsgi components now too.
Nicholas Dudfield
have no real interest in learning it.
If Robert Brewer has personally promised assistance that would be a very
good case for using CherryPy.
As time permits I might be able to help somewhat if a CherryPy stack is
used.
I personally much prefer CherryPy + Co over what I have seen of Django
but I doubt I'll be contributing much compared to others.
Marcus von Appen
[...]
> >
> > Also, is it possible to do this at google code instead?
> >> http://code.google.com/p/pygame/
> >>
> >
> > Sounds reasonable - google already has the whole functionality for the
> > project,
> > Julian currently hosts privately. It might be good to use google's wiki
> > there
> > and a seperate website SVN branch. Especially since the final system could
> > be
> > adopted by other community-driven projects.
> >
> >
> Also lots of people already have google accounts on there, and it's not
> hosted on someones personal server.
>
> Keeping it separate from the main pygame svn makes sense, since it's
> probably going to be a separate group of people, and also it's fairly easy
> to allow access to it.
After discussing certain things with Julian, something like this might
make the most sense:
SVN hosting on google.
Trac (which I'd prefer over google's homebrewn software) on dev.pygame.org.
Why that? First of all, one of the website requirements is to have a bug
tracker and wiki integrated instead of having anything hosted on
different domains as it is at the moment.
dev.pygame.org could act as central platform for pygame-related
development. Users can keep track of pygame projects, which are in a
planning and early development state and the trac system running there
can act as routing station to the different SVN repositories hosted
elsewhere (google, pygame, ...).
In the long term, this also allows us to have a development wiki and bug
tracking already around and the only thing left to do would be to
integrate them seamlessly into the final pygame.org website.
For the current time, we could redirect dev.pygame.org to Julian's
webserver, then, once trac is up and running on pygame.org (which should
be relatively easy to be realised), let it point to the local trac. That
way we have no dead URL mess and people do not need to visit various
sites (and create different accounts) just to file bugs for (either)
pygame project.
We also do not have the data scattered ony google's wiki, pygame.org and
wherever else.
Regards
Marcus
Marcus von Appen
> I doubt I'd be contributing in any form whatsoever if Django is used. I
> have no real interest in learning it.
>
> If Robert Brewer has personally promised assistance that would be a very
> good case for using CherryPy.
Well, I'd like to keep the decision those, who will do the major work on
the whole website system, which probably will be Julian and Orcun.
If they both say, Django is their preferred target system (and the GSoC
proposals were written that way) as they have a lot of expertise, we
should not insist on CherryPy :-).
Regards
Marcus
Nicholas Dudfield
> Well, I'd like to keep the decision those, who will do the major work on
> the whole website system, which probably will be Julian and Orcun.
>
programmers./
/
Nicholas Dudfield
to write but I had a brain malfunction.
jug
I'm kinda amazed about some points:
1) Did anyone read my concept?
Some of the discussed ideas here I had before but no one cared.
2) I created a trac an you said "nice!" and created a Google project.
3) This project was an gsoc candidate and AFAIK all applicants wanted
to use Django. At least 2 of them (Orcun and me) would like to do it
even without google. Now you say "let's do it with cherrypy" because
you don't know Django. Hm. I my view, both - Django and cherrypy -
are mighty enough for our needs, thus its a relig. question of
faith. But you
asked so to do it. So, here we are! We have time and (only) want to
do it
with Django, cause we don't know cherrypy as you don't know Django.
Maybe here are some php-experts why do it with php?
4) Even if you don't know Django, you can participate by helping to develop
the concept, writing specific requirements, care about design, read the
old code, transfer it and write new templates (Django templates are
really
easy to learn). If we use Trac the way things are going, there will
be some
work on adapting it by editing the Trac templates and style to make
it fit
into the whole page. Then, care about plugins that could be useful or
necessary (auth, notification, feeds, irc-announcer, ...). Be sure
you can help
us even when using Django for the backend.
Regards
Jug
PS, well, I'm a slow writer, so I agree with Marcus.
Nicholas Dudfield
"""
If most of the people that are motivated to do the work already have experience
with Django I think it would just be more work for all involved using a custom
CherryPy stack.
Contributors would have to follow the evolving `framework`. They'd have to spend
time documenting it if they wanted to make it easy for more people to
contribute. They'd likely waste time arguing over the best ways of doing things
and which components to use. Would it ever get done? Or would everyone just get
sick of it?
For an opensource project with potentially quite a few people working on it (The
more the better right?) then I'd say Django would be a good fit due to the
`free` unified documentation and resources surrounding it and the fact that
every one is on the same page.
"""
Nicholas Dudfield
"""
I doubt I'd be contributing in any form whatsoever if Django is used. I
have no real interest in learning it.
If Robert Brewer has personally promised assistance that would be a very
good case for using CherryPy.
*As time permits I might* be able to help somewhat if a CherryPy stack
is used.
I personally much prefer CherryPy + Co over what I have seen of Django
*but I doubt I'll be contributing much compared to others.*"""
I actually took time out of my day to argue the case for using Django.
jug
is that it does not support subdomains. Thus, pygame.org/dev would
be much easier to handle.
To concretize, please specify the structure again. What would Trac be
used for? Replace the current wiki and add a ticket system for bug-tracing
and more (enhancements, etc)?
So, the rough structure would be
Django
- News
- Flatpages
- Projects
Trac
- Wiki
- Ticket system
- code browser
- (maybe more?)
I'm going to test the django-trac thing today. If we use now my Trac please
try to keep the concept up to date and edit it with our discussion results.
- Jug
sheepjxx
nice tools.
--------------------------------------------------
From: "jug" <j...@fantasymail.de>
Sent: Saturday, April 25, 2009 9:26 PM
To: <pygame...@seul.org>
Subject: Re: [pygame] PyGame Website Rewrite
Evan Kroske
> <snip />
> One of the few weaknesses of Django
> is that it does not support subdomains. Thus, pygame.org/dev would
> be much easier to handle.
>
Unless I misunderstood, everybody was saying that someone should create
a subdomain with the server administrator tools and simply run Django
from there. I don't think they want Django running in the top-level web
directory and creating a dev subdomain. If you're saying that Django
can't be confined to a single directory and that it must be run from the
top-level web directory, I have nothing to add.
Regards,
Evan Kroske
ab3
version = models.FloatField()
the version should be a string beceause it allows for different kind
of version formats like 1.0.4b
On Apr 23, 8:35 pm, jug <j...@fantasymail.de> wrote:
> Hello,
>
> to organize the development process, I've set up a SVN-repo and a small
> Trac athttp://pygameweb.no-ip.org/trac/
jug
> # need a numeric version? or save it as string?
> version = models.FloatField()
> the version should be a string beceause it allows for different kind
> of version formats like 1.0.4
is rubbish. Better by last update or so.
I've just changed that ;)
Lenard Lindstrom
> After discussing certain things with Julian, something like this might
> make the most sense:
>
> SVN hosting on google.
>
> Trac (which I'd prefer over google's homebrewn software) on dev.pygame.org.
>
> Why that? First of all, one of the website requirements is to have a bug
> tracker and wiki integrated instead of having anything hosted on
> different domains as it is at the moment.
>
> dev.pygame.org could act as central platform for pygame-related
> development. Users can keep track of pygame projects, which are in a
> planning and early development state and the trac system running there
> can act as routing station to the different SVN repositories hosted
> elsewhere (google, pygame, ...).
>
> In the long term, this also allows us to have a development wiki and bug
> tracking already around and the only thing left to do would be to
> integrate them seamlessly into the final pygame.org website.
>
> For the current time, we could redirect dev.pygame.org to Julian's
> webserver, then, once trac is up and running on pygame.org (which should
> be relatively easy to be realised), let it point to the local trac. That
> way we have no dead URL mess and people do not need to visit various
> sites (and create different accounts) just to file bugs for (either)
> pygame project.
>
> We also do not have the data scattered ony google's wiki, pygame.org and
> wherever else.
>
>
appropriate for now. I have just been looking again at Trac and at first
it looks like a good choice. The wiki has a clean markup that accepts
Python code without mangling it. But I have two questions. One, how easy
will it be to import the existing Pygame wiki pages into Trac? Two, can
we really use the Trac with the Web SVN and Pygame SVN? (*)
Lenard
(*) I believe no to the first, yes to the second
(http://trac.edgewall.org/wiki/TracInstall#OptionalRequirements).
Nirav Patel
with the SVN is a huge plus and if possible, should be put into place
as soon as possible. That is, having Trac up on dev.pygame.org before
starting the web development work for use with both the website
project and Pygame in general would be nice.
I really dislike the Bugzilla we are currently using, and judging by
the lack of activity on it, I imagine many others do too.
Nirav
Lenard Lindstrom
experienced enough in this area to make a recommendation. I will look at
them more closely. Django is favored at the new Pygame web site
development Trac. Of major consideration is the ease with which the
content of the existing site can be ported to the new site. I cannot
even comment on that as I don't know how the existing site is
implemented, though I guess Python is involved somewhere.
As for what I can contribute, I am taking this more as a learning
opportunity than anything. I could probably write applications to port
information and maybe convert wiki to pages if something doesn't already
exist. But I will leave the framework stuff to others. I have also
played around a bit with PovRay so could create some simple 3D effect
controls like in the midi.py Pygame example.
Lenard
Lenard Lindstrom
looks good for that. The wiki will be useful as well. But the Trac
subversion features will be useless with a google SVN for the web site
development. So we will have to use whatever google offers. But I
believe we can set it up for Pygame's SVN.
Lenard
jug
using Trac with google SVN is not directly provided, but could be done.
You need
to mirror the repo on the server where Trac is running on. Because you have
no access to SVN-hook scripts at google it's a bit tricky. Have a look at
http://rc98.net/googsvnsync. I'm not a SVN expert so who could undertake
this?
We are still waiting for the current database structure, but I think it
will be
possible to import old wiki data. At http://trac-hacks.org/wiki/script
are some
scripts to import wiki data from other wikis (eg. MoinToTrac). I think
we could
write an equal script.
- Jug
jug
I just got the DjangoAuthIntegration (1) Trac plugin working. With this
plugin, you can login to Django, go to Trac and are logged in (without
reentering username and password). After logging out at Django,
you are logged out with Trac, too. Thats really cool.
Now need some testing.
-Jug
René Dudfield
the main way we do bugs with pygame is through the mailing list. The internet is a bug tracker.
I wrote a blog post about the reasons why the mailing list is good, and what 'the internet is a bug tracker' means:
http://renesd.blogspot.com/2008/02/bugs-search-not-categorise.html
I personally think trac is a bit rubbish, and have been happy with James Paige hosting bugzilla for us.
The current pygame wiki just uses simple html. So should be fairly straight forward to convert... or we could just leave it in html. Since most programmers know html anyway... way more than trac markup.
Lenard Lindstrom
certainly something can be figured out with for the wiki pages. It is
not a new problem.
--
Lenard Lindstrom
<le...@telus.net>
Lenard Lindstrom
I don't know about Trac's tracking system but I find bugzilla difficult
as it requires report generation. How to get a listing of recent bugs is
not obvious.
The html markup in the current wiki is not strict XHTML. We do want the
new site to generate properly formed XHTML pages, or am I mistaken. Also
Python code gets mangled, '<' replaced with '<' for <code> sections.
This is probably a data entry problem though. But whatever wiki engine
is chosen it has to handle this properly. Trac does. Do any of the html
tag wikis handle it right? What alternate wiki do you suggest?
Lenard
René Dudfield
I suggest using the current one - rewritten in python, and fixing that bug. I think that's the only code mangling bug it has?
Yeah, the code in the wiki is probably best described as non-strict html... or just html... which is not strict itself. The wiki does some sanitising on the html after entry. It's only a few lines of code to add a gui editor like tinymce... so we could add that for those who don't want to use markup.
cheers,
René Dudfield
sorry if my emails come across as not being thankful, or appreciative of your efforts... little pygame is my baby(and is many other peoples baby too of course), so I'm maybe overly protective of it.
Thanks partly to you(and others), and your enthusiasm the project seems like it might actually get done, and it is very much appreciated by me and everyone else I'm sure.
Hello,
I'm kinda amazed about some points:
1) Did anyone read my concept?
Some of the discussed ideas here I had before but no one cared.
2) I created a trac an you said "nice!" and created a Google project.
Thanks for progressive way you went forward and are getting things done.
However, this will be a team effort, and we need to discuss our plan before doing things.
I don't really know you, and I was a little worried you might disappear in a week/month. Whereas a google site won't just disappear. I'm not saying that you would disappear... just that it's very common for people to disappear on open source projects.
There's no need to rush into making a decision about what we want to do with the website. One of the main goals of the rewrite was so that more pygame contributors could modify the websites code. Three active contributors to pygame have expressed a preference for using cherrypy(pymike, nick, and I). pymike doesn't write code for pygame itself, but has put more games/projects on the pygame website than almost any other person(him and Ian seem to be in a race to produce the most things). pymike also expressed interest in working on the website in late January.
The three main 'clients' for this project are...
- the coders who make pygame,
- the people who make games with pygame,
- and the people who contribute to the website.
So whilst it's important that the people making the website are happy with the choice of tools, it's also important the other main groups are happy with the choices.
As one of the people contributing to pygame for the longest time, I want to make sure the website is done nicely, and is an improvement to the current one. It's probably the most important part of pygame, so I think it deserves some more discussion.
3) This project was an gsoc candidate and AFAIK all applicants wanted
to use Django. At least 2 of them (Orcun and me) would like to do it
even without google. Now you say "let's do it with cherrypy" because
you don't know Django. Hm. I my view, both - Django and cherrypy -
are mighty enough for our needs, thus its a relig. question of faith. But you
asked so to do it. So, here we are! We have time and (only) want to do it
with Django, cause we don't know cherrypy as you don't know Django.
Maybe here are some php-experts why do it with php?
Yes, however there's also other people interested in working on the website.
Rather than have you decide what is used, we need to have a discussion. I didn't know you didn't like cherrypy or not... and I don't know yet what other people want to use.
btw, I have looked at django in the past. Here you can see a post I made in 2006 about some security problems I found in Django http://renesd.blogspot.com/2006/08/django-security.html I mention this just to show that I'm not entirely unfamiliar with django.
Let me explain some history, and further outline parts of the current website...
The current website is made with PHP and some website technology made by Phil which he used to make dozens of websites professionaly. This is what Phil chose to use as the website maintainer in early 2005. This time around we wanted to make it a team effort, and to make it in python. Last time we(the mailing list and Pete Shinners) decided to let whoever the website maintainer is make it in whatever they wanted to make it with. The main goal was to get a good website.
This time we decided it would be better to do it in python, and also have a team of website maintainers. Since not so many pygame developers people know PHP, and that has meant that it's been a bit difficult for us to make changes... we had to bother Phil mostly to change things. Luckily the website has worked fairly well without needing to make all that many changes to the code. It's pretty amazing really what Phil has done with the website, and especially considering how it has worked for many years without many code changes, and is now a very popular website.
Before 2005, the project was more Pete Shinners personal project with a bunch of helpers... now it has evolved into group project with 8 or so main fairly active contributors, and a whole bunch of sometimes contributors... with millions of downloads, 10,000's of people using it to make things, and millions of people playing the games made with pygame. There's over 1100 projects listed on pygame.org. Now both Pete, and Phil have somewhat moved onto other things from pygame, but both pop their heads in occasionally... and Pete still does things like pay for domain registration, and also helps us interact with the seul.org people, and occasionally writes stuff on the mailing list.
As shown above, the current pygame website has been a success. Sure it could be improved... but it's been really quite good.
There's been a plan for a little while to do a website rewrite in python... and some parts are already done in python(build/testing bots, viewvc, the old pygame pcr).
In January pymike said he wanted to work on the pygame website. After that Phil prepared the source code so we can release it publically in a svn(which Marcus and I are almost done checking it to make sure no ones personal/private information is disclosed). I am currently looking at the current database, so I can remove any personal/private information... so we can make the database public (expect a few days before this is ready).
Here is a blog post I wrote about the design work I did concerning integrating httpd support into pygames event queue: http://renesd.blogspot.com/2009/01/pygame-pywebsite-website-with-joystick.html It doesn't look like much, but it took a number of iterations to figure out a simple way of doing this. pygame.org was going to be a test ground for pygame httpd integration - but I'm not interested in doing that now.
I say these things to show that there has already been work done to start a new website rewrite.
The bugzilla bug tracker is run and maintained by one person(James Paige) on a separate server, and also a separate person runs the buildbot/testing machines (Brian). Nicholas has also contributed to the build server, and a test result collector(written in python/php)... which is planned to be put into the new website(it's not used yet).
There's also heaps of people who write stuff on the pygame.org wiki, and comment sections and contribute in other ways... like adding projects!
The main amount of writing and talk about pygame happens on other peoples websites... forums etc. If you do a search on google for pygame, and limit it to the last days updates to websites... lots more gets written about pygame elsewhere... not on the mailing list, the pygame.org website, or on the irc channel. I think that's great... leave the talk for other places... leave pygame.org to concentrate on the projects.
We have specifically decided not to have a forum on the website(search the mailing list for discussion on reasons why).
Projects are the main focus of the website. It sounds like an obvious thing, but many other projects websites don't do this. For example the django web page main focus... is django. What we are making should always be the main focus... not pygame itself. The other part of this, is it's rewarding people who make games/multi media, not people who write internet posts. It also provides feedback to people and their games. A main motivation for people making stuff is to get feedback, and show people what they've done. So in that way, it's a nice little community of people who make stuff. People making games/other projects, talking with other people who make stuff.
We could do lots better by the projects of course. Especially with there being almost 5-10 updates per day some times... it would be better if people could get more feedback on their projects. So if you make an update, it can be off the front page very quickly.
Another factor with projects is trying to make it easy for people to find code other people have written. We could do way better in this area. That is, promoting libraries made for pygame, and making it easier to find libraries made for pygame... even perhaps having development infrastructure for pygame (like testing/build/packaging/distribution bots etc).
The other main point of the website is information. With wiki pages, documentation and such. I think this is covered fairly well, but could use a few improvements. The documentation uses google code search to allow people to find examples of how to use functions/classes. The search on the website is done using a site specific google search... and also a web search in the wiki.
The news section on the web page has main, and important points we would like to tell people about. It's generally not updated very often(which is a good thing really). I think it's probably got too much space devoted to it at the moment.
The seul people run the viewvc for online svn browsing for us(again written in python). Many other websites access the pygame svn and provide useful services too... eg launchpad, ohloh, google code search, etc etc.
The wiki is used for many free-form purposes too. Like for a Cook Book(code recipies), and a basic todo/goal list for making pygame releases.
http://pygame.org/wiki/todo#Website
The WHATSNEW page gets updated from the file in svn called... WHATSNEW. Which pygame developers are supposed to put new changes in. However since the last release this practice has lapsed a little. However... we have svn commit logs! So before the next release I will go through the commit logs, and update it... and then update the web page.
There is an admin section on the web page that people can update menu links, non-wiki pages, projects, doc comments etc.
There are feeds for various things... like svn updates, mailing list updates, projects updates, news, etc. They're listed on the feeds page. Not all feeds are from the pygame website directly... svn feed is by launchpad. mailing list feed is done using google groups.
The pygame website as outlined above... is actually multiple websites hosted and maintained by separate people. In effect, we already have a big web team.
... and I think that's most of the main parts of the website(s).
4) Even if you don't know Django, you can participate by helping to develop
the concept, writing specific requirements, care about design, read the
old code, transfer it and write new templates (Django templates are really
easy to learn). If we use Trac the way things are going, there will be some
work on adapting it by editing the Trac templates and style to make it fit
into the whole page. Then, care about plugins that could be useful or
necessary (auth, notification, feeds, irc-announcer, ...). Be sure you can help
us even when using Django for the backend.
Sure. I'll be happy with whatever the group decides to use, and whatever plan we decide to follow.
I'd still like to hear from anyone else who wants to contribute. Are you happy using either django, or cherrypy? Or would you only be interested working on it using one of them?
René Dudfield
Hi René,
I don't know about Trac's tracking system but I find bugzilla difficult as it requires report generation. How to get a listing of recent bugs is not obvious.
hi again,
This is the page which makes bugzilla easier to use. It has links to the main things it's used for.
http://pygame.motherhamster.org/
I do note however that it has been maintained quite well by James Paige... in that the website hasn't had much downtime, and it isn't full of spam which seems to happen to some trac instances.
However, as I mentioned before I'm not really interested in bug trackers... preferring to search for bugs... so I'll leave that choice up to the rest of you. I think there's more bugs reported if you search for 'pygame bug' (with only the last months/week/day entries listed) in google, than get reported in bug trackers.
eg.
http://www.google.com/search?q=pygame+bug&as_epq=&as_oq=&as_eq=&num=10&lr=&as_filetype=&ft=i&as_sitesearch=&as_qdr=w&as_rights=&as_occt=any&cr=&as_nlo=&as_nhi=
cu,
Marcus von Appen
> On Mon, Apr 27, 2009 at 3:52 AM, Lenard Lindstrom <le...@telus.net> wrote:
>
> > Hi René,
> >
> > I don't know about Trac's tracking system but I find bugzilla difficult as
> > it requires report generation. How to get a listing of recent bugs is not
> > obvious.
> >
Seconded - bugzilla is a pain due to various reasons, be it its high
complexity, the need to register and the really weird 'do not simply
file a bug' avoidance.
The main reason to use trac would be to have a lot of features in one
well-maintained and solid system. The wiki, milestone management and
such stuff (suitable for gsoc tasks and subprojects) and even a good bug
tracker are something to favour over an own hackish solution in my
opinion.
We won't need to implement a wiki ourselves as trac comes with it. A bug
tracker for those who do not like mailing lists would be given, - one
that does not require a master degree in report generation and bug
filing management to use it (*).
[...]
> I do note however that it has been maintained quite well by James Paige...
> in that the website hasn't had much downtime, and it isn't full of spam
> which seems to happen to some trac instances.
I only noticed that for projects, which are mostly stalled or where the
whole website seems to be completely unmaintained or dead.
If spam from anonymous users should go out of hands, we can change trac
to accept only registered users for bug reports (which'd be a pity,
though).
> However, as I mentioned before I'm not really interested in bug trackers...
> preferring to search for bugs... so I'll leave that choice up to the rest of
I'm preferring the mailing list, but some people do not want to
subscribe there or whatever and for those a small bug tracker is the
perfect solution.
(*) Many people, including me are pretty annoyed by bugzilla and a lot
do not even report bugs (including me) to projects like mozilla anymore,
as they do not want to register yet another account just for a short
bug, for which they even have to spend half a day on filling out all
boxes.
Regards
Marcus
Lenard Lindstrom
Thanks for the link to the bug tracker main page. A bug tracker may not
be the most productive way to discover reported bug but what it does
organize the repair effort. The mailing list has worked so far, but is
not a good place to search out the current status of a bug. It also
leaves us reliant on gmane.org, the only mailing list archive of the two
listed with a proper search option. Even if Pygame does not get a bug
tracker its website's framework will, or at least it will while under
development.
Lenard
Lenard Lindstrom
beautifulsoup. Another issue is maintaining consistently across pages.
Using <h..> tags doesn't work. Remembering what header level to use when
is bothersome. If new, more descriptive, header tags could be added that
would be great. And a preview function.
Lenard
René Dudfield
the website also uses some stuff to filter out things like javascript. Hopefully there is something similar available for python now. Does lxml support that? Failing that, will have to convert one of the ones from php. feedparser in python is pretty good for that... however it still has some problems.
It's a must for user submitted website content, no matter the markup language.
cu,
Lenard Lindstrom
lxml parses the html to an xml ElementTree structure. It is also a validating
parser, so a restrictived DTD could be provided to reject scripts. Or the tree
could just be searched.
Lenard
--
Lenard Lindstrom
<le...@telus.net>