[Pkg-exppsy-maintainers] The future of PyEPL

[Michael Hanke]

Hey,

On Tue, Jan 29, 2008 at 01:57:07PM -0500, Per B. Sederberg wrote:
> Michael has sent a couple chats my way asking about whether there is
> pyglet in the future of the PyEPL because that is a major factor in
> his decision to maintain a debian package for pyglet.
> 
> I'll outline my thoughts below, in no particular order:
> 
>  - PyEPL currently works (relatively well) with the pygame backend.
>  - Pyglet has very few dependencies (possibly zero) beyond the base
> OpenGL libraries and OpenAL for sound (though the current version of
> pyglet does not expose the sound recording capabilities of OpenAL).
Pyglet also has an ALSA interface. The dependencies I have identified so
far are (from debian/control):

  python-ctypes | python (>= 2.5)
  libgtk2.0-0
  libgl1 | libgl1-mesa-swx11
  libglu1 | libglu1-mesa
  libasound2 | libopenal0a

  (plus a few more that are deps of the above)

So, there are deps, but they are most likely installed on every system.
Not sure about the situation on win32, though.

>  - Pyglet is less-bloated than pygame and fast
>  - I would love for pyglet to be the backend for both video and sound
> in pyepl, but it would take a large effort to refactor the current
> code-base.  I am still on the fence as to whether it would make more
> sense to start from scratch because there's a lot of code in the
> current pyepl that is there specifically to deal with the pygame
> backend.
>  - One of our short-term goals is to get pyepl working on Windows.
> Both pygame and pyglet supposedly work on windows (though I have no
> personal experience with this), it just takes more dependencies to
> install pygame.
>  - Pyglet does not have joystick support for those who may need/want it.
Ah! Good point.

>  - I like the way pyglet handles movies better than pygame.

> So, to sum up.  I really would love to have pyglet become the pyepl
> backend, however, I don't want to face the coding project right now to
> port it.  On a related note, if there is no debian package for pyglet,
> then the likelihood of working with pyglet drops even more.  That
> should not be reason alone for us to package pyglet up, but they do
> feed off one another.  For example, if I know there's a debian package
> and I can easily experiment with pyglet, then it increases the
> likelihood that I would not be able to take pygame anymore and would
> feel compelled to push towards the new pyglet-based pyepl version.

<from later message>

> - pygame is very mature and well-supported.
> - pyglet just had it's first release and has a single author.
> - One can see on the mailing list that, while pyglet's author is
> quite skilled, he is also relatively set in where he sees the future
> of pyglet (there are some relatively contentious threads with
> discussions of suggested features and improvements.)  Please note that
> I could be misinterpreting the tone of the thread.
IMHO this is a valid concern. I just made the same experience in a
private conversation.

My conclusion ATM is: Let's refactor and modularize PyEPL. It might
eventually use pyglet as an alternative backend (like Yarik) suggested.
Adding the ability for an alternative backend will enforce modularity, I
guess.

I'm still very concerned about an attempt of a full rewrite. Many projects do
not survive such an attempt (I myself failed two times :( ). Rewriting PyEPL
while maintaining a working version also needs additonal ressources (which are
already very limited).

So even if a (slow) refactoring process is suboptimal in a technical
sense, it might provide the highest probability to finally build a PyEPL 2.0.
;-)


Cheers,

Michael

-- 
GPG key:  1024D/3144BE0F Michael Hanke
http://apsy.gse.uni-magdeburg.de/hanke
ICQ: 48230050