I may have missed something here. What's wrong with the stock Python in Lion?
(I'm asking because that's my default work environment, and I've had good success with it). R. On 09/06/2012, at 18:51, Winston Wolff <[email protected]> wrote: > I've switched to using the c-types branch of pyglet which works nicely with > 64-bit python to avoid this. I've found it works very nicely on OSX > > hg+https://code.google.com/r/evilphillip-cocoa-ctypes2/ > > -ww > On Jun 9, 2012, at 10:25 AM, Jonathan Hartley wrote: > >> Premature send, sorry. Final text appended below: >> >> On Saturday, June 9, 2012 6:16:51 PM UTC+1, Jonathan Hartley wrote: >> I'm running on OSX, on which I understand Pyglet needs a 32 bit Python >> executable. >> >> The .dmg from python.org is a 'universal binary', which prefers to run in 64 >> bit mode, unless invoked using: >> >> arch -i386 python my-pyglet-app.py >> >> This works. However, my application has no top level "my-pyglet-app.py" >> script. Instead it has a 'main()' function which I've declared as an >> executable entry point in my setup.py: >> >> entry_points = { >> 'console_scripts': ['myapp = mypackage.main:main'], >> } >> >> When running 'setup.py install' or 'setup.py develop', an executable script >> is now generated which calls my 'main' function, and this makes sure that, >> for example, I'm running against local source when developing, versus >> running against installed modules after installation. >> >> This means I don't have an opportunity to insert the 'arch -i386' command. >> The generated script has a hashbang line pointing to whatever 'python' is in >> my active virtualenv. >> >> I could manually tweak the generated script every time I start work on the >> project. But then I'm not sure how I'd do the equivalent when it comes to >> deploying a project like this to end-user's machines. >> >> I could give in, and abandon the use of setup.py's "entry_points", and >> create my own top-level executable script to run python using the 'arch' >> command. But in my memory of years gone by, this approach has problems of >> its own, which is why I switched to this arrangement. >> >> Does anyone else have this problem? Is there a canonical "one way to do it" >> right? >> >> -- >> You received this message because you are subscribed to the Google Groups >> "pyglet-users" group. >> To view this discussion on the web visit >> https://groups.google.com/d/msg/pyglet-users/-/04RosZqmpUEJ. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/pyglet-users?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "pyglet-users" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/pyglet-users?hl=en. > -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en.
