OSX: "arch -i386" versus "setup.py develop"

[Jonathan Hartley]

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-application.py" script. Instead it has a 'main()' function which I've declared as an executable entry point using an entry in my setup.py:

        entry_points = {
            'console_scripts': ['{0} = {0}.main:main'.format(NAME)],

[Jonathan Hartley]

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?

[Winston Wolff]

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

> --
> 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 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.

[Rui Carmo]

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.

[Tristam MacDonald]

On Tue, Jun 12, 2012 at 5:12 PM, Rui Carmo <rui....@gmail.com> wrote:

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).

Not everybody likes the stock python. It is however the simplest to get pyglet running at this point (and the environment that pyglet is probably the most tested with) .

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.

That hasn't been true for a very long time.

The issue was that Carbon is not supported under 64-bit, but we added Cocoa support a long time back. You don't even need the ctypes branch to take advantage of that - there is an older PyObjC port to Cocoa in the main repository.

--

Tristam MacDonald

http://swiftcoder.wordpress.com/

[Jonathan Hartley]

Many thanks for the explanation, I had misread the "pyglet requires PyObjC when in 64-bit Python" exception to mean that things would be simpler if I was using a 32-bit Python.

"pip install pyobjc==2.2" works just fine, pyglet runs happily, and all the "lipo" and "arch" wrinkles can be deleted from my scripts/README. Much rejoicing.

  Jonathan

[Jonathan Hartley]

On Tuesday, June 12, 2012 10:12:40 PM UTC+1, Rui Carmo wrote:

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.

I'm not on Lion.