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.
