The future of pyglet, revisited.

[Ben Smith]

Hello all,

If there are critical issues in the 1.1.4 branch, we can look at
fixing them in a 1.1.5 release.

Better, though, to move to 1.2 if the maintenance branch is working
well enough.  Alex Holkner put together a summary of feature changes
here: http://groups.google.com/group/pyglet-users/msg/9733fab4436e635d
and the entire thread at
http://groups.google.com/group/pyglet-users/browse_thread/thread/700c63844ece86c2/e5b22b9d0c6320c4
is worth going over.

There are some other things that have occurred in the interim.
Unrelaible timing on Windows, and issues with 64-bit OSX 10.6, off the
top of my head.  I feel that finding a way to make the testing system
more automatic would be nice, too, though there are very likely some
situations where tests must be inspected visually.  I'd like to see
these things in 1.2, but that's just an opinion and I'm afraid I
haven't kept up with the developments on the OSX things.

Also, to open up a fun can of worms - now seems like a good time to
move to a dvcs, particularly Mercurial since google code supports it.
Are there compelling reasons to stick with SVN?  I'd used git before
this discussion came up in August, and have been working with both git
and Mercurial since.  A lot of the issue ports and backports would
have been easier with one of these, due to the overhead in tracking
down historical diffs to find out which things changed and when.  I
would personally prefer working with hg over SVN.

Thanks,
-b

[Tristam MacDonald]

On Sun, Jan 24, 2010 at 1:35 PM, Ben Smith <benjamin.c...@gmail.com> wrote:

I'm afraid I haven't kept up with the developments on the OSX things.

I am currently without a Mac (64-bit or otherwise), so my Cocoa backend is unfortunately on hold until such time as I manage to acquire one - not something I can afford in the near future. If anyone feels up to taking a stab at completing the port, I would be glad to offer help and advice.

Also, to open up a fun can of worms - now seems like a good time to
move to a dvcs, particularly Mercurial since google code supports it.

+1 for Mercurial. While git has some advantages, the ease of transition from SVN to Mercurial seems a win to me, along with the ability to stick with googlecode. 

--
Tristam MacDonald
http://swiftcoder.wordpress.com/

[Ben Smith]

Ok. Is it correct to say that pyglet can still be used on OSX 10.6 64-
bit by some hoop-jumping? You must use a 32-bit compiled Python for
it? I'm not on 10.6 or 64-bit myself though that could happen some
day - what must one do to use pyglet as-is on Snow Leopard 64? Of
course, someone able to do the work would be better :)

Also, an addendum to my first message on this thread, I found this
discussion of possible 1.2 features: http://code.google.com/p/pyglet/wiki/ReleaseSchedule

-b

On Jan 24, 10:49 am, Tristam MacDonald <swiftco...@gmail.com> wrote:
> On Sun, Jan 24, 2010 at 1:35 PM, Ben Smith

> <benjamin.coder.sm...@gmail.com>wrote:

[Casey Duncan]

I would support moving to mercurial, since Google code now supports it
and especially if it eases patch integration, which it seems like it
should. Should also make branch management easier, which was something
I never liked much in svn.

As for 1.2 I think we should come up the minimum amount of work
necessary to get out a first alpha. I propose that anything Alex was
not confident in should be omitted from a first alpha to get it out
more quickly. There's probably a bunch of work in just testing and
verifying things. And I'm unsure what the state of the documentation
is.

I'm currently working on a game engine project that builds on top of
pyglet (and is intended to support pygame one day as well, but not
yet), so I have a vested interest in seeing development continue,
especially the OSX cocoa support. I also have access to machines
running 10.4, 10.5 and 10.6 so at a minimum I can help test. I'd be
interested in helping see it through, though I'm not well versed in
the Cocoa apis. I don't want to over-promise, but I can lend some
cycles. Tristam, if you could post a little summary on what works, is
considered done and what needs attention, I can see if there is
anything I can help with.

-Casey

> --
> You received this message because you are subscribed to the Google Groups "pyglet-users" group.
> To post to this group, send email to pyglet...@googlegroups.com.
> To unsubscribe from this group, send email to pyglet-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en.
>
>

[Casey Duncan]

pyglet 1.1.x works fine for me on 10.6 with 32-bit python.

-Casey

[Casey Duncan]

The release schedule points out some backward compat work. That's
pretty important. I'm assuming 1.2 will be b/w compatible with 1.1?
Regardless, one major task is to identify current incompatibilities
and at a minim document them, and ideally provide some shims for
compatibility.

-Casey

On Sun, Jan 24, 2010 at 11:56 AM, Ben Smith
<benjamin.c...@gmail.com> wrote:

[George Oliver]

On Jan 24, 10:35 am, Ben Smith <benjamin.coder.sm...@gmail.com> wrote:

> Also, to open up a fun can of worms - now seems like a good time to
> move to a dvcs, particularly Mercurial since google code supports it.

On a related note though not exactly development related, what is the
chance of moving the user contributions in the Pages of the Google
Group to a pyglet user wiki? Should one of us just start one or do the
devs have a plan to incorporate this with the pyglet website? (it
doesn't appropriate in the Google code wiki).

[Tristam MacDonald]

On Sun, Jan 24, 2010 at 1:56 PM, Ben Smith <benjamin.c...@gmail.com> wrote:

Ok.  Is it correct to say that pyglet can still be used on OSX 10.6 64-
bit by some hoop-jumping?

Yes. You can either compile a custom 32-bit python, or use the leftover 32-bit python from Leopard if you happen to have upgraded from Leopard.

[Richard Jones]

On 25/01/2010, at 1:22 PM, Tristam MacDonald wrote:
> On Sun, Jan 24, 2010 at 1:56 PM, Ben Smith <benjamin.c...@gmail.com> wrote:
> Ok. Is it correct to say that pyglet can still be used on OSX 10.6 64-
> bit by some hoop-jumping?
>
> Yes. You can either compile a custom 32-bit python, or use the leftover 32-bit python from Leopard if you happen to have upgraded from Leopard.

I installed ActivePython over my Snow Leopard which solved a bunch of my issues, including being able to compile extensions like PIL...

Richard

[Florian Bösch]

On Jan 24, 7:35 pm, Ben Smith <benjamin.coder.sm...@gmail.com> wrote:
> Also, to open up a fun can of worms - now seems like a good time to
> move to a dvcs, particularly Mercurial since google code supports it.
> Are there compelling reasons to stick with SVN?  I'd used git before
> this discussion came up in August, and have been working with both git
> and Mercurial since.  A lot of the issue ports and backports would
> have been easier with one of these, due to the overhead in tracking
> down historical diffs to find out which things changed and when.  I
> would personally prefer working with hg over SVN.

I'd very much appreciate Mercurial <rollseyes>. If you do go to hg,
then please sign me up with push rights (or pull from my repo), I'd be
looking forward to get some, or any, tickets with patches I filed
closed.

[Ben Smith]

A separate wiki may be a good idea, the problem is contributors and
maintenance.

I added a couple of pages to the google code wiki anyhow, since it's
already there.

http://code.google.com/p/pyglet/wiki/ProjectsUsingPyglet

http://code.google.com/p/pyglet/wiki/PygletCookbook

I agree that it would be good to integrate the groups pages. My main
constraint is time, I have a few hours here and there.

-b

[George Oliver]

On Jan 28, 11:50 am, Ben Smith <benjamin.coder.sm...@gmail.com> wrote:
> A separate wiki may be a good idea, the problem is contributors and
> maintenance.
>
> I added a couple of pages to the google code wiki anyhow, since it's
> already there.

Currently you need to be added to the pyglet dev list to edit the
Google code wiki, right? This makes sense, but probably isn't the best
for a pyglet user wiki in my opinion.

If no one objects, I'd be happy to set something up and migrate
resources from the pages/files here.

[Ben Smith]

> Currently you need to be added to the pyglet dev list to edit the
> Google code wiki, right? This makes sense, but probably isn't the best
> for a pyglet user wiki in my opinion.

Yes, it also looks like one can add project contributers that don't
have repository write access but could edit the wiki, though.

>
> If no one objects, I'd be happy to set something up and migrate
> resources from the pages/files here.

This would also work.

-b

[Adam Bark]

On 24 January 2010 18:35, Ben Smith <benjamin.c...@gmail.com> wrote:

 

Also, to open up a fun can of worms - now seems like a good time to
move to a dvcs, particularly Mercurial since google code supports it.
Are there compelling reasons to stick with SVN?  I'd used git before
this discussion came up in August, and have been working with both git
and Mercurial since.  A lot of the issue ports and backports would
have been easier with one of these, due to the overhead in tracking
down historical diffs to find out which things changed and when.  I
would personally prefer working with hg over SVN.

I still don't really "get it" as far as dvcs's go can you explain it at all? Does everybody that had rights on the SVN server get it on Mercurial?

Cheers,
Adam.

[Ben Smith]

To answer your last question first, yes, commit authorization should
be the same.

Mercurial (aka hg) and git are what I have some experience with, along
with SVN and CVS - so this is from that context.

Both hg and git are geared around branchy development with multiple
people doing commits. As soon as you clone a repository, you've got
the whole thing there on your disk. You can hop back and forth in the
project's history without talking with the server. You can clone it
from your disk again, without talking to the server. Since these are
local operations, they are very fast. With subversion, going through
history and changing branches requires server communication.

Since you've got the repository local, you can make changes and commit
them locally, then when you're satisfied with them, push them up to
the server all at once. This is also handy if you want to hack on
something but you're going to be offline - suppose you want to do a
few different things to the source code, fix a bug, add a feature. In
the SVN world, you'd end up with several files modified for different
reasons and have to cherry pick commits to make a coherent history.
With a local repository, you can commit each change in its context,
then push them to another repository with a coherent history for free.

One additional useful feature is that you can publish your repository,
either temporarily hosted from your machine in a trusted environment,
or set up something more secure for long term public hosting. This
way a maintainer could go through your repo and cherry pick the
patches they'd like to put in the main source archive, and they can do
this with full project history on both your end and their end. As
soon as they clone your repository, they have all the changes they
need locally and don't need to hit your repository again until they
want an update.

These tools allow for more flexible development workflows while at the
same time making it simpler and faster to branch and merge changes
from many sources.

And I'm not against SVN, it is an effective tool.

-b

On Jan 29, 10:13 am, Adam Bark <adam.jt...@gmail.com> wrote:

[Florian Bösch]

On Jan 29, 8:22 pm, Ben Smith <benjamin.coder.sm...@gmail.com> wrote:
> And I'm not against SVN, it is an effective tool.

I am against SVN :) for the things you just described beneficial about
mercurial (which in my eyes makes SVN less effective relatively)

[Adam Bark]

Thanks a lot for that explanation it was very helpful, quick question though; if two people are working on the same thing how does it go about merging the two different sets of commits into something coherent?

Cheers,
Adam.

[Ben Smith]

It does what it can automatically, but there are situations where you
still must resolve conflicts by hand.

-b

On Jan 29, 5:16 pm, Adam Bark <adam.jt...@gmail.com> wrote:

[Florian Bösch]

On Jan 30, 2:53 am, Ben Smith <benjamin.coder.sm...@gmail.com> wrote:
> It does what it can automatically, but there are situations where you
> still must resolve conflicts by hand.

I rarely find myself in this situations as the merge is quite good,
also, there's a fairly good tutorial/overview how it all works:
http://hgbook.red-bean.com/read/a-tour-of-mercurial-merging-work.html

Also I'd recommend http://hgbook.red-bean.com/read/ as well as
http://mercurial.selenic.com/wiki/Tutorial http://mercurial.selenic.com/wiki/UnderstandingMercurial
http://mercurial.selenic.com/wiki/QuickStart

[Adam Bark]

Thanks Ben I think I get it now.
Cheers for your time,
Adam.