Re: [Pythonmac-SIG] Building against OpenGL

[Chris Barker via Pythonmac-SIG]

As usual, once you pose the question -- you find the answer.

The trick was not to try to link directly, but rather to use Apple's nifty
"Framework" concept:

extra_link_args.append("-framework OpenGL")

Posting this in case anyone else happens upon it.

-CHB




On Tue, Mar 22, 2022 at 12:47 PM Chris Barker  wrote:

> I have an app that uses a C (Cython) extension that needs to link against
> the OpenGL libs (libGL and libGLU)
>
> Here's the code that used to work:
>
> gl_libraries = ["GL", "GLU"]
>
> ...
>
> gl_include_dirs.append(
> "/System/Library/Frameworks/OpenGL.framework/Headers",
> )
>
> gl_library_dirs.append("/System/Library/Frameworks/OpenGL.framework/Libraries",
> )
>
> And this resulted in this linking line that fails:
>
> clang -bundle -undefined dynamic_lookup
> -Wl,-rpath,/Users/chris.barker/miniconda3/envs/maproom39/lib
> -L/Users/chris.barker/miniconda3/envs/maproom39/lib
> -Wl,-rpath,/Users/chris.barker/miniconda3/envs/maproom39/lib
> -L/Users/chris.barker/miniconda3/envs/maproom39/lib
> build/temp.macosx-10.9-x86_64-3.9/libmaproom/Tessellator.o
> -L/System/Library/Frameworks/OpenGL.framework/Libraries -lGL -lGLU -o
> build/lib.macosx-10.9-x86_64-3.9/libmaproom/
> Tessellator.cpython-39-darwin.so
> ld: library not found for -lGL
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> error: command '/usr/bin/clang' failed with exit code 1
>
> Some of this makes sense -- as System/Library/Frameworks/OpenGL.framework 
> doesn't
> have Libraries and Headers anymore. However, it also doesn't have the
> headers or libraries (that I can tell) anywhere else in there.
>
> Oddly, the compiler is finding the headers somewhere -- not sure where.
>
> Google has failed me here -- but a few hints:
>
> 1) ctypes had to be updated to find the libs -- that was done, and ctypes
> seems to be working. but what it does is:
>
> In [1]: from ctypes.util import find_library
> In [2]: find_library("OpenGL")
> Out[2]: '/System/Library/Frameworks/OpenGL.framework/OpenGL'
>
> but /System/Library/Frameworks/OpenGL.framework/OpenGL doesn't exist on
> my system at all.
>
> Reading a bit -- it seems that OS-X is doing some kind of cached libs
> trickery -- but how do I tell distutils / clang how to find those libs??
>
> Enclosed is the whole setup.py in case I've missed a detail.
>
> Sometimes Apple Drives me crazy! Thanks for any hints --
>
> -CHB
>
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR(206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
>
> chris.bar...@noaa.gov
>


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] Building against OpenGL

[Chris Barker via Pythonmac-SIG]

I have an app that uses a C (Cython) extension that needs to link against
the OpenGL libs (libGL and libGLU)

Here's the code that used to work:

gl_libraries = ["GL", "GLU"]

...

gl_include_dirs.append(
"/System/Library/Frameworks/OpenGL.framework/Headers",
)

gl_library_dirs.append("/System/Library/Frameworks/OpenGL.framework/Libraries",
)

And this resulted in this linking line that fails:

clang -bundle -undefined dynamic_lookup
-Wl,-rpath,/Users/chris.barker/miniconda3/envs/maproom39/lib
-L/Users/chris.barker/miniconda3/envs/maproom39/lib
-Wl,-rpath,/Users/chris.barker/miniconda3/envs/maproom39/lib
-L/Users/chris.barker/miniconda3/envs/maproom39/lib
build/temp.macosx-10.9-x86_64-3.9/libmaproom/Tessellator.o
-L/System/Library/Frameworks/OpenGL.framework/Libraries -lGL -lGLU -o
build/lib.macosx-10.9-x86_64-3.9/libmaproom/Tessellator.cpython-39-darwin.so
ld: library not found for -lGL
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
error: command '/usr/bin/clang' failed with exit code 1

Some of this makes sense -- as
System/Library/Frameworks/OpenGL.framework doesn't
have Libraries and Headers anymore. However, it also doesn't have the
headers or libraries (that I can tell) anywhere else in there.

Oddly, the compiler is finding the headers somewhere -- not sure where.

Google has failed me here -- but a few hints:

1) ctypes had to be updated to find the libs -- that was done, and ctypes
seems to be working. but what it does is:

In [1]: from ctypes.util import find_library
In [2]: find_library("OpenGL")
Out[2]: '/System/Library/Frameworks/OpenGL.framework/OpenGL'

but /System/Library/Frameworks/OpenGL.framework/OpenGL doesn't exist on my
system at all.

Reading a bit -- it seems that OS-X is doing some kind of cached libs
trickery -- but how do I tell distutils / clang how to find those libs??

Enclosed is the whole setup.py in case I've missed a detail.

Sometimes Apple Drives me crazy! Thanks for any hints --

-CHB



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
#!/usr/bin/env python

"""
setup.py for libmaproom to build python extensions

right now - it mostly is to be used as follows:

python setup.py build_ext --inplace

"""
import sys

from Cython.Distutils import build_ext
from setuptools import setup, Extension
from ctypes.util import find_library


version_path = "../maproom/_version.py"
exec(compile(open(version_path).read(), version_path, 'exec'))

# find the various headers, libs, etc.
import numpy
gl_include_dirs = [numpy.get_include()]
gl_library_dirs = []
gl_libraries = ["GL", "GLU"]

if sys.platform.startswith("win"):
gl_libraries = ["opengl32", "glu32"]
elif sys.platform == "darwin":
gl_include_dirs.append(
"/System/Library/Frameworks/OpenGL.framework/Headers",
)
gl_library_dirs.append(
 #find_library("OpenGL"),
 "/System/Library/Frameworks/OpenGL.framework/Libraries",
)

# Definition of compiled extension code:
bitmap = Extension("libmaproom.Bitmap",
   sources=["libmaproom/Bitmap.pyx"],
   include_dirs=[numpy.get_include()],
   extra_compile_args = ["-O3" ],
   )

shape = Extension("libmaproom.Shape",
  sources=["libmaproom/Shape.pyx"],
  include_dirs=[numpy.get_include()],
  extra_compile_args = ["-O3" ],
  )

tessellator = Extension("libmaproom.Tessellator",
sources=["libmaproom/Tessellator.pyx"],
include_dirs=gl_include_dirs,
library_dirs=gl_library_dirs,
libraries=gl_libraries,
extra_compile_args = ["-O3" ],
)

render = Extension("libmaproom.Render",
   sources=["libmaproom/Render.pyx"],
   include_dirs=gl_include_dirs,
   library_dirs=gl_library_dirs,
   libraries=gl_libraries,
   extra_compile_args = ["-O3" ],
   )

# pytriangle extension

DEFINES = [("TRILIBRARY", None), # this builds Triangle as a lib, rather than as a command line program.
   ("NO_TIMER", None), # don't need the timer code (*nix specific anyway)
   ("REDUCED", None),
   ]

# Add the defines for disabling the FPU extended precision   ]
## fixme: this needs a lot of work!
##it's really compiler dependent, not machine dependent
if sys.platform == 'darwin':
print("adding no CPU flags for mac")
## according to:
## http://www.christian-seiler.de/projekte/fpmath/
## nothing special is required on OS-X !
##
## """
## the precision is always determined by the largest operhand type in 

Re: [Pythonmac-SIG] Error with mimetype on OS-X 11 (Big Sur)

[Chris Barker via Pythonmac-SIG]

OK,

I've gotten a bit farther into debugging this.

Turns out it's not about that particular error, it's probably about the
fact that modules couldn't be loaded at start up due to security checks in
the new OS.

We've signed the app but that's not fixing it :-(

Starting the app at the command line at least gets me output, and I see a
lot of errors like this:

  File
"PyInstaller-3.4-py3.6.egg/PyInstaller/loader/pyiboot01_bootstrap.py", line
149, in __init__
  File "ctypes/__init__.py", line 348, in __init__
OSError: dlopen(OpenGL, 10): no suitable image found.  Did find:
file system relative paths not allowed in hardened programs

I am really confused as to how they could disallow relative paths -- how
else could you bundle a library?

though maybe it's a lib outside the bundle that's using relative paths ?

More digging needed, but if anyone has any ideas, I'm all ears.

Also:

- Has anyone gotten a PyInstaller App to work on OS-X 11 ?

- Even better, one that uses OpenGL?

Thanks,

-CHB



On Thu, Dec 16, 2021 at 11:21 AM Chris Barker  wrote:

> I've just got a new mac with OS-X 11.6 (still Intel).
>
> But when I try to run a PyInstaller built application, I get this error:
>
> No document available for {'mime': 'application/x-maproom-project-zip',
> 'loader':  0x7f9669ce6e10>, 'uri': 'template://default_project.maproom'}
>
> And the app won't start.
>
> This has worked just fine on numerous previous OS-X versions.
>
> I have the source code, but the developer that built it is no longer with
> us, so it'll take b e a bit to get up to speed, and I don't even know where
> to start! Is this a PyInstaller issue? or a code issue, or ???
>
> Hints:
>
> The application is called MapRoom (maproom) it works with "projects" that
> are essentially a zip file with all the info required in it.
>
> I think, on startup, it loads a empty default project, presumably
> "default_project.maproom"
>
> So I think that's where the app startup code is barfing, not having the
> mime type registered properly. But where / how am I supposed to do that?
>
> or maybe it's not a mime type registration issue, but simply that the
> template can't be found -- so a path issue in the App bundle??
>
> Anyway, I'll be digging into this deeper in the source code, but if anyone
> has seen anything like this, any hints would be appreciated!
>
> Thanks,
>
> -CHB
>
>
>
>
>
>
>
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR(206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
>
> chris.bar...@noaa.gov
>


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Error with mimetype on OS-X 11 (Big Sur)

[Chris Barker via Pythonmac-SIG]

thanks Ronald.

I"m afraid starting from the common line (with open) results in the same
error, and no messages to the console.

Everything is in the app bundle.

and I did find the template in the bundle:

MapRoom.app/Contents/Resources/maproom/templates/default_project.maproom

so I think what's changed is the root for the uri it's using:

 'uri': 'template://default_project.maproom'

Now to figure out where / how that's set.

-CHB


On Thu, Dec 16, 2021 at 12:05 PM Ronald Oussoren 
wrote:

>
>
> On 16 Dec 2021, at 20:21, Chris Barker via Pythonmac-SIG <
> pythonmac-sig@python.org> wrote:
>
> I've just got a new mac with OS-X 11.6 (still Intel).
>
> But when I try to run a PyInstaller built application, I get this error:
>
> No document available for {'mime': 'application/x-maproom-project-zip',
> 'loader':  0x7f9669ce6e10>, 'uri': 'template://default_project.maproom'}
>
> And the app won't start.
>
> This has worked just fine on numerous previous OS-X versions.
>
> I have the source code, but the developer that built it is no longer with
> us, so it'll take b e a bit to get up to speed, and I don't even know where
> to start! Is this a PyInstaller issue? or a code issue, or ???
>
>
> Hints:
>
> The application is called MapRoom (maproom) it works with "projects" that
> are essentially a zip file with all the info required in it.
>
> I think, on startup, it loads a empty default project, presumably
> "default_project.maproom"
>
> So I think that's where the app startup code is barfing, not having the
> mime type registered properly. But where / how am I supposed to do that?
>
> or maybe it's not a mime type registration issue, but simply that the
> template can't be found -- so a path issue in the App bundle??
>
> Anyway, I'll be digging into this deeper in the source code, but if anyone
> has seen anything like this, any hints would be appreciated!
>
>
> I’m afraid you’ll have to dig in.   The error message seems to indicate
> that mime type itself works, there is a (non-standard) mime type in the
> error message.
>
> Does running the application from the terminal give you more clues?
>
> How is the application normally installed, it is just an app or does it
> use an installer that may install more files? I’ve had issues in the past
> when copying an app bundle to a new machine and forgetting to copy some
> resource files that weren’t in the app bundle.
>
> Ronald
>
>
> Thanks,
>
> -CHB
>
>
>
>
>
>
>
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR(206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
>
> chris.bar...@noaa.gov
> ___
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
>
>
> —
>
> Twitter / micro.blog: @ronaldoussoren
> Blog: https://blog.ronaldoussoren.net/
>
>

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] Error with mimetype on OS-X 11 (Big Sur)

[Chris Barker via Pythonmac-SIG]

I've just got a new mac with OS-X 11.6 (still Intel).

But when I try to run a PyInstaller built application, I get this error:

No document available for {'mime': 'application/x-maproom-project-zip',
'loader': , 'uri': 'template://default_project.maproom'}

And the app won't start.

This has worked just fine on numerous previous OS-X versions.

I have the source code, but the developer that built it is no longer with
us, so it'll take b e a bit to get up to speed, and I don't even know where
to start! Is this a PyInstaller issue? or a code issue, or ???

Hints:

The application is called MapRoom (maproom) it works with "projects" that
are essentially a zip file with all the info required in it.

I think, on startup, it loads a empty default project, presumably
"default_project.maproom"

So I think that's where the app startup code is barfing, not having the
mime type registered properly. But where / how am I supposed to do that?

or maybe it's not a mime type registration issue, but simply that the
template can't be found -- so a path issue in the App bundle??

Anyway, I'll be digging into this deeper in the source code, but if anyone
has seen anything like this, any hints would be appreciated!

Thanks,

-CHB









-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] "pythonw" in a Unix build

[Chris Barker via Pythonmac-SIG]

Ned suggested I bring this conversation over here from python-dev, so here
it is.

What I'd like to see done is have the "pythonw" wrapper buildable in an
otherwise non-framework build.

I *think* there are no real technical show stoppers, but it would take some
auto-conf magic, which I am fully unqualified to take on.

Anyone interested in helping make this happen ?

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Failure on pip upgrade attempt

[Chris Barker]

On Tue, Feb 13, 2018 at 10:18 AM, Gerrie Shults  wrote:

> Thanks for the pointer. PYTHONPATH clearly bit me.
>
> I’m going to have to read up on virtualenvs.
>

you don't even need to go there to get rid of PYTHONPATH -- they kind of
require you to get rid of PYTHONPATH -- many environment, one PYTHONPATH --
really bad.

but what you need is a way to make your code available to the python
instances (Or virtualenvs) that you want it to be. Heer are my thoughts on
that:

http://pythonchb.github.io/PythonTopics/where_to_put_your_code.html

-CHB





> Gerrie
>
>
> On Feb 13, 2018, at 10:11, Glyph  wrote:
>
> PYTHONPATH itself is a bit of an anachronism :).  It's the past,
> virtualenvs are the future!  https://orbifold.xyz/pythonpath.html
>
> (If you're using PyObjC and avoiding virtualenvs for that reason, check
> out https://github.com/glyph/venvdotapp )
>
> -g
>
> On Feb 13, 2018, at 9:51 AM, Gerrie Shults  wrote:
>
> Thank you, Barry. Your PYTHONPATH suspicion was correct.
>
> I have been away from Python for many years. My PYTHONPATH pointed to
> personal directories, which happened to include a 15-year old module named
> ‘html’.
>
> Clearing that solved my problem.
>
> Thanks again,
> Gerrie
>
> On Feb 12, 2018, at 11:56, Barry Scott  wrote:
>
> html module is shipped with python 3.6.4.
>
> Only thing I can think of is that your PYTHONPATH is interfering in some
> way.
>
> $ python3
> Python 3.6.4 (v3.6.4:d48ecebad5, Dec 18 2017, 21:07:28)
> [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import html
> >>> html
>  framework/Versions/3.6/lib/python3.6/html/__init__.py'>
> >>> from html.parser import HTMLParser
> >>> HTMLParser
> 
> >>> import sys
> >>> sys.path
> ['', '/Library/Frameworks/Python.framework/Versions/3.6/lib/python36.zip',
> '/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6',
> '/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload',
> '/Library/Frameworks/Python.framework/Versions/3.6/lib/
> python3.6/site-packages']
> >>>
>
> Barry
>
>
> On 12 Feb 2018, at 16:05, Gerrie Shults  wrote:
>
> Before my original post, I looked up html.parser in the Python
> documentation, and everything I saw indicated to me that it was already
> installed.
>
> I have now looked again at the documentation and can find examples using
> html.parser, but nothing that tells me how to install it.
>
> How do I install it? And how can I find what is already installed, and
> what is available to install without having to download more?
>
> Thanks,
> Gerrie Shults
>
> On Feb 11, 2018, at 18:59, 樊佳亮  wrote:
>
> You should first install html.parser this error report is about html.parser
> Then rerun pip command
>
> 发自我的 iPhone
>
> 在 2018年2月12日，上午5:32，Gerrie Shults  写道：
>
> I’m trying to get the latest version of pip to use to install Flask.
>
> I have a fresh install of Python 3.6.4, and I executed "pip3 install -U
> pip”, per the instructions from "https://pip.pypa.io/en/stable/installing/“,
> and got the result below.
>
> Why isn’t html.parser available as part of the standard install? What do I
> need to do to make this work?
>
> Thanks for any help.
>
> Gerrie Shults
>
>
>
>
> $ pip3 install -U pip
> Traceback (most recent call last):
>   File "/Library/Frameworks/Python.framework/Versions/3.6/bin/pip3", line
> 7, in 
> from pip import main
>   File "/Library/Frameworks/Python.framework/Versions/3.6/lib/
> python3.6/site-packages/pip/__init__.py", line 28, in 
> from pip.vcs import git, mercurial, subversion, bazaar  # noqa
>   File "/Library/Frameworks/Python.framework/Versions/3.6/lib/
> python3.6/site-packages/pip/vcs/subversion.py", line 9, in 
> from pip.index import Link
>   File "/Library/Frameworks/Python.framework/Versions/3.6/lib/
> python3.6/site-packages/pip/index.py", line 31, in 
> from pip.wheel import Wheel, wheel_ext
>   File "/Library/Frameworks/Python.framework/Versions/3.6/lib/
> python3.6/site-packages/pip/wheel.py", line 39, in 
> from pip._vendor.distlib.scripts import ScriptMaker
>   File "/Library/Frameworks/Python.framework/Versions/3.6/lib/
> python3.6/site-packages/pip/_vendor/distlib/scripts.py", line 14, in
> 
> from .compat import sysconfig, detect_encoding, ZipFile
>   File "/Library/Frameworks/Python.framework/Versions/3.6/lib/
> python3.6/site-packages/pip/_vendor/distlib/compat.py", line 85, in
> 
> from html.parser import HTMLParser
> ModuleNotFoundError: No module named 'html.parser'
> $
>
> ___
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
>
>
> ___
> Pythonmac-SIG 

Re: [Pythonmac-SIG] please advise me

[Chris Barker]

This is really a better question for the VPython folks, but:

1) Have you clicked "Don't show this warning again"? if so, does it keep
coming back?

2) you will need to tell us more about exactly what you installed, and how
you are running the application. i.e. "I open a Terminal Windows and type
" or " I doubple click on the ??? icon, or ???

and when in this whole process does the above dialog appear?

-CHB



On Tue, Feb 21, 2017 at 7:27 PM, Maher Zidan  wrote:

> Hello,
> I am new to programming in python, one thing is really important to me to
> keep learning python is the Vpython Launcher app.
> It keep hanging out when i use it for raw_input function or i want to
> Visualize anything from my script on it.
> there is a A Error or note message keep showing whenever i tried to open
> the Vpyhton directly. it is below…Please let me know what i can do fast to
> fix i could not see anything related solution on the internet. Thanks
>
>
> Maher Zidan
> m90.zi...@gmail.com
> 415-960-9722 <(415)%20960-9722>
>
>
>
> ___
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
>
>


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] [Pyobjc-dev] py2app release delayed

[Chris Barker]

On Tue, Dec 27, 2016 at 11:36 AM, Ronald Oussoren 
wrote:

> As an aside to this: I’m considering to remove the site-packages.zip file
> from the app bundle and store everything outside off zipfiles. A lot of
> code works inside zipfiles, but there are too many exceptions and with the
> transition from eggs to wheels even less packages will care to document
> whether or not they work with their code in zipfiles.
>

I think this is a good idea -- these days, size really only matters when
you're shipping the app, not when it's on disk (or SSD) -- so why bother
with the zip?

 > I have an issue about copying enough information into the application to
ensure pkg_resources.require works, but haven’t gotten around to doing the
work for that because I don’t need the feature myself.

>
> AFAIK pkg_resources should work for accessing datafiles though. Could you
> file a bug for the pytz problem on py2app’s tracker?
>

pkg_resources is a pain in general, and particularly always has been with
py2app and the like.

but I've usually gotten it to work OK by explicitly listing the package to
be included, so that py2app will bundle the whole thing.


> It seems that py2app will package up all the files in a package, not just
> the
> .py files. Is that the algorithm that is used?
>
>
> That’s correct. All files in the directory of a python package are assumed
> to be important.
>

which is why it usually works OK for things like pytz. :-(

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] PyObjC and macOS 10.12 (Sierra)

[Chris Barker]

On Tue, Dec 13, 2016 at 11:16 AM, Glyph Lefkowitz 
wrote:

> If we were to add s PyObjC build to conda-forge, the full stack should
> "just work".
>
> And conda forge has s CI system set up to auto build for various python
> versions
>
> http://conda-forge.github.io/#add_recipe
>
>
> Why would this be necessary?  Can't conda just install the wheels from
> PyPI?
>

Well, maybe -- conda has grown better support for pip lately, so it may
work OK.

Back in the day, mixing conda and pipi got ugly fast, so I far prefer to
make a native conda package for everything.

conda also has a non-framework build of Python -- not sure if that would
cause any issues with the wheels.

-CHB



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Need help with Python Library link error in OS X 10.11.6

[Chris Barker]

> brew install --HEAD libimobiledevice
>

odd -- this:

http://brewformulas.org/Libimobiledevice

doesn't make it look like it needs Python.

I think this is a question for the brew folks.

-CHB




> and following error message was displayed at the end of this command run
>
> **
>
> checking consistency of all components of python development
> environment... no
> configure: error:
>  Could not link test program to Python. Maybe the main Python library has
> been
>  installed in some non-standard library path. If so, pass it to configure,
>  via the LDFLAGS environment variable.
>  Example: ./configure LDFLAGS="-L/usr/non-standard-path/python/lib"
>  ===
> =
>   ERROR!
>   You probably have to install the development version of the Python
> package
>   for your distribution.  The exact name of this package varies among them.
>  ===
> =
>
> ***
>
> I tried to run following command ./configure PYTHON_LDFLAGS="-lpython3.4m"
> as suggested however it failed as it couldn't find "configure" in current
> user's folder. I also searched in other file system to locate "configure"
> but couldn't find it. I need to revolve this Python lib link issue and need
> suggestions on how to do it. Things I need help  on:
> 1. Where can I find "configure" to run the suggested LDFLAGS command. If
> it is not available in my Mac, what is the next step for me.
> 2. Do I need to install any Python builds to get rid of this error and be
> able to run brew install --HEAD libimobiledevice  command successfully.
>
> Thank you
>
> Regards
> Manohar
>
>
> ___
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
>
>


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] What does it take to run a GUI app?

[Chris Barker]

On Mon, Aug 25, 2014 at 8:32 AM, Aaron Meurer aaron.meu...@continuum.io
wrote:

  you can. but you sure don't want to from the start of your development
   process. And there are hybrid command-line GuI apps like iPython or
 anything
  that wants to pop up, say, a matplotlib graph. So we do need a command
 line
  python that can run a GUI.

 Yes, matplotlib is big here. The default backend on OS X uses a Cocoa
 GUI, which is almost completely broken if not run with a framework
 build (see https://github.com/matplotlib/matplotlib/issues/665).

 However, I just tested both Anaconda pythonw and the python.org python
 (both 3.4), and neither work directly with matplotlib. Both require
 you to start IPython and type %matplotlib or the plot will not show.


That's standard iPython -- it has to do with event loops capturing (or not)
the REPL. Nothing to so with the issue at hand. YOu can also start up
iPython with this turned on (ipython --pylab, I think)

 well Anaconda would need to be able to re-locate, that's kind of the point
  -- so probably why they didn't just grab that build to begin with. Not
 that
  they couldn't make a re-locatable Framework. But problem at hand is about
  the app bundle and start up executable, not the Framework anyway.

 Yes, relocatability is essential. Conda can make path replacements in
 plain text files at install time, but in general it's best if
 everything uses relative paths.


hence the avoidance of a Framework -- though _maybe_ one could build a
re-locatable framework.


 The app bundle seems to work just as well as the framework.  If
 something explicitly looks for WITH_NEXT_FRAMEWORK it fill fail
 (although we could probably forcibly set that to 1 if it helps).


yup -- these are orthogonal -- for the GUI issue you need the app bundle.
So the trick at hand is how to re-direct an executable in a normal
location to the one in the app bundle. While Ned may be right that there
could be a better way to do it, the short bit of code (pythonw.c) in the
python source has been working well for years -- seem worth giving it a
shot with Anaconda.

As for a Framework build, one advantage it would give is keeping the python
lib dir cleanly separated from the rest of the Anaconda lib dir (this has
caused problems for me, anyway). There are other ways to do that anyway, if
you choose to do so.

-Chris



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] What does it take to run a GUI app?

[Chris Barker]

Folks,

Over on the list for the Anaconda distribution, we've run into a limitation
in our understanding of the whole app bundle, etc business.

The problem is thus:

Anaconda is currently built with the old python / pythonw dichotomy.

python is a standard unix-style executable -- great for command line apps,
web servers, what have you. But you get the dreaded:


This program needs access to the screen.
Please run with a Framework build of python, and only when you are
logged in on the main display of your Mac.


when you try to run a GUI app (this error message from wxPython)

pythonw, on the other hand, is a shell script that re-directs to a python
that is inside a hand-built application bundle:

#!/bin/bash
export
PYTHONEXECUTABLE=/Users/chris.barker/PythonStuff/Anaconda/anaconda/bin/python
/Users/chris.barker/PythonStuff/Anaconda/anaconda/python.app/Contents/MacOS/python
$@

This all sort-of works. But it's a pain, because you may not know when you
start up an app, whether it needs to access the Window manger (like
iPython, for instance). And now I need to put pythonw in my #! lines,
which may fail on other *nix systems, and...

One thought is to simply have python be the same shell script as
pythonw but there is concern that having it be a re-directing shell
script may cause problems for some use cases.

I know that this has been solved for years in the python.org installer. So
how is that done?

Anaconda doesn't seem to want to make their python a proper framework build
-- don't know why not -- would there be any downside? But is it possible to
build the python executable so it can access the GUI system without
structuring their whole python install?

Thanks,
  -Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] What does it take to run a GUI app?

[Chris Barker]

On Fri, Aug 22, 2014 at 2:04 PM, Aaron Meurer aaron.meu...@continuum.io
wrote:

 It does cause problems. I'm not entirely clear what happens with
 nested shebang lines, but you can't put

 #!/Users/aaronmeurer/anaconda/bin/pythonw

 as your shebang. If you do, it will try to run the script in bash. It has
 to be

 #!/bin/bash /Users/aaronmeurer/anaconda/bin/pythonw


OK, then this is broken anyway for scripts that need a GUI and want to use
a #! line to start.so another solution really would be good.


 A (possibly weak) argument for not wanting to do a full framework
 build is that it would break backwards compatibility with file
 locations (possibly weak because the right symlinks might make
 everything work).  I believe the real reason is that it's (as far as
 we can tell) unnecessary complexity, especially given that the fake
 app bundle seems to work just as well.


for this, perhaps. But it's not all all complex, and might actually solve
antoher problem (OK, my other problem) of keeping the python libs separated
from all the other Anaconda libs...

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] What does it take to run a GUI app?

[Chris Barker]

Thank Ned,


 Anaconda is currently built with the old python / pythonw dichotomy.


 On vanilla OS X python builds, there is no difference between python and
 pythonw; that's been the case going back many years.


exactly -- I was quite surprised when i ran into this with Anaconda -- I
had totally forgotten about pythonw -- and the goal is to let us all
continue to forget about it.

  In fact, as of

3.4, we no longer make the pythonw* symlinks.


Another reason why we really don't  want to use that...
  pythonw, on the other hand, is a shell script that re-directs to a python
 that is inside a hand-built application bundle:

 #!/bin/bash
 export

PYTHONEXECUTABLE=/Users/chris.barker/PythonStuff/Anaconda/anaconda/bin/python

/Users/chris.barker/PythonStuff/Anaconda/anaconda/python.app/Contents/MacOS/py
 thon
 $@

This is something supplied by Anaconda?


yup.


  I know that this has been solved for years in the python.org installer.
 So
  how is that done?



 A framework build, like used in the python.org installer, creates a
 Python.app app bundle within the framework:

 /Library/Frameworks/Python.framework/Versions/x.y/Resources/Python.app


OK -- this is more or less what Anaconda does, though without the whole
Framework, just the app bundle.


   The tricky part is
 that a bootstrap executable, built from the somewhat confusingly named
 pythonw.c (http://hg.python.org/cpython/file/3.4/Mac/Tools/pythonw.c),
 is what is actually installed into the framework bin directory and
 symlinked to from /usr/local/bin/ or wherever.  The bootstrap
 executable's job is to essentially transparently launch Python.app from
 the command line.


ah hah! that is what Anaconda's pythonw script does, but not as well. This
is what we've been looking for.


   That is, when you type:

 /usr/local/bin/pythonx.x
 or
 /Library/Frameworks/Python.framework/Versions/3.4/bin/pythonx.y

 you are first executing the bootstrap executable and it then spawns or
 execs the real interpreter executable under Python.app so that Python
 runs as a app that can be a gui process.


Is there any downside to this? a measurable amount of overhead?


 Now, these days, most of the time you probably don't need to be a gui
 process, especially since we no longer support the obsolete deprecated
 Mac Carbon-based API wrapper functions in the standard library.  And if
 you are building you own gui app, presumably you can use py2app to
 produce your app as its own app bundle.


you can. but you sure don't want to from the start of your development
process. And there are hybrid command-line GuI apps like iPython or
anything that wants to pop up, say, a matplotlib graph. So we do need a
command line python that can run a GUI.


 I'm not familiar with wxPython at all but, if it doesn't already, it
 might be able to take the approach Tcl/Tk does on OS X.  Tk seems to do
 some tricks to make itself a gui process and it also has an embedded
 Wish.app at least when Tk is built as a framework.  But I haven't looked
 closely at it.  The relevant code in the the Tk file
 macosx/tkMacOSXInit.c.


well, _maybe_ the alpha wx project, Phoenix could do this, but the legacy
version will be around for a while. And it looks like folks are having
problems with native Cocoa GUIs as well (at least with matplotlib, that I
know of)



  Anaconda doesn't seem to want to make their python a proper framework
 build
  -- don't know why not -- would there be any downside? But is it possible
 to
  build the python executable so it can access the GUI system without
  structuring their whole python install?

 One issue might be that the current framework builds are meant to be
 installed at a fixed path, by default /Library/Frameworks.  You can
 change that at build time but we don't support changing it at install or
 run time.


well Anaconda would need to be able to re-locate, that's kind of the point
-- so probably why they didn't just grab that build to begin with. Not that
they couldn't make a re-locatable Framework. But problem at hand is about
the app bundle and start up executable, not the Framework anyway.

Without knowing more, I'd look to solving the issue in wx rather than
 Python since it might affect other users as well.


well, this isn't jsut a wx problem. IT seems beter to me to solve it at teh
python level, rather than the separate GUI level.



 The Python framework
 GUI stuff is quite old and hasn't really been closely examined in a long
 time.  There *might* be better ways to do it today.


There might -- but if it ain't broke thanks for pointing us to the
relevant code -- if the Anaconda folks want to fix this, that looks like a
good place to start.

Or if anyone has any ideas for a better way... Maybe whatever tk does to
trick the system?

Thanks again,

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   

Re: [Pythonmac-SIG] MacPython and automating wheel builds

[Chris Barker]

Matthew,

I would like some feedback on an idea I had for providing a
 wheel-building service via the MacPython organization.


Do you mean the gitHub MacPython organization? If so, then yes, this is
exactly the kind of thing I had in mind when I started that.

Following up an idea and code by Matt Terry [1], I've made a general
 repo called 'terryfy', with tools for building Python projects on the
 travis-ci OSX virtual machines [2].

 Meanwhile, Olivier Grisel from scikit-learn kindly gave me access to the
 scikit-learn rackspace account for uploading built wheels.

 This made it rather easy to make a series of repos to build OSX wheels
 automatically. An example is the 'h5py-wheels' repo [3], to build
 OSX wheels for the h5py project.


One thought on this -- I had envisioned one repo that would contain the
stuff to build a whole bunch of projects -- not one per project. One reason
is that ere is a lot of shared effort -- for instance, there are multiple
packages that require the HDF5 libs -- the code to build HDF5 itself should
be shared, ideally.

This may not work with with the travis links -- if everything in a repo
would need to be rebuilt when only one had been changed, though.


 There are currently terryfy-based wheel-building projects for h5py
 [3], numpy / scipy [5], matplotlib [6], cython [7], scikit-image [8],
 scikit-learn [9], pandas [10], Pillow [11], tornado [12],
 numexpr [13] and Markupsafe [14].  These all build wheels against the
 Python.org Python.


great work!

So, I was wondering if y'all agreed that it was sensible to start
 transferring these repos to the MacPython organization.


yes -- it makes loads more sense to spread the load here.

In this way, we could have a collection of say 25 MacPython organization
 repos that would provide an OSX wheel-building service to projects that
 need it.  It could be a central point for advice and help on building
 OSX wheels.


sounds good to me. Thanks for putting all this effort in!

-Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] avoiding system's easy-install.pth with custom distribution

[Chris Barker]

On Tue, Sep 10, 2013 at 11:16 PM, Ned Deily n...@acm.org wrote:

 The behavior is the result of a feature added in 2.7 for Issue4865 which
 appends the site-packages directory for the Apple-supplied system Python
 to sys.path of a Python framework build.  With hindsight, I don't think
 this was a good idea


yeah, probably not


 The path appends occur in the standard library site module.  You could
 patch it in your own interpreter to not include /Library/Python; you
 might be also be able to do it by supplying a sitecustomize module.
 See site.py for details.


Could you simply remove it from sys.path at start-up for your app?
(probably when you toss out PYTHONPATH)

-Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Fwd: Can any cross platform gui framework limitations be filled with ctypes / pyobjc or other?

[Chris Barker - NOAA Federal]

 Do you know any Qt apps for mac?

 There are lots of Qt apps with Mac ports; most are crappy because they make
 little effort to get the Mac UI details right.

I think QGIS falls into that camp...

http://www.qgis.org/

 VirtualBox and Parallels are
 two Qt apps that do a better job with the UI.

If done right, I suppose you shouldn't know  it's a QT app. So I may
have bias from that.

-Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Fwd: Can any cross platform gui framework limitations be filled with ctypes / pyobjc or other?

[Chris Barker - NOAA Federal]

On Wed, Jul 10, 2013 at 2:35 AM, Paul Wiseman poal...@gmail.com wrote:

 I've used wxpython a lot in the past, and maintain some code that uses it
 and I do like it, there are a couple of bits that have put me off though.
 There doesn't seem to be an obvious way to implement an MVC type pattern
 with it.

I
ve always felt that:

1) slavishly following MVC is pretty pointless

2) to the extent you do follow it, it's very application-specific, so
Ive never quite understood what an out-of-the-box MVC framework would
look like.

3) You can certainly do it with wx.

 I haven't used Qt much at all yet but QML looks extremely
 interesting and pretty powerful.

there is the XRC format, but when looking at it, it looks like it jsut
 makes things more complicated -- decoupling strictly GUI code and
belongs-with-the-GUI code seems pointless to me. And I really like
code-generated GUI layout. I suspect that that approach makes much
more sense with C++ than Python.

 This signal and slots in qt reminds me a
 lot of the outlet actions in the iOS world as well which helps a lot at
 keeping everything de-coupled.

I haven't used signals and slots, but I agree that wx events are bit
stifling. A number of folks recommend pubsub for a more de-coupled
approach.

 I've found an awful lot of bugs with wx over
 the time I've been using it as well which has put me off somewhat, but
 that's probably true for a lot of systems/frameworks of that size that you
 get very familiar with and use a lot.

Well, wx definately doesn't get as much attention on the Mac -- I've
seen more issues there. Maybe QT gets more love -- what with KDE and
all, it probably has a significantly larger user/developer base.

-CHB

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] py2app questions..

[Chris Barker - NOAA Federal]

Ronald,

Did you mean this to go to the list? I've forwarded it on...

Anyway, thanks for the notes -- I'll keep all this in mind when I
build that app again.

 I've learned a few things from this.

 1) this is odd:
  right near the top, I see:
 prescript.py
 imports: Image
  that's the prescript for the PIL recipe -- Im not using PIL, it
 seems it's runnign nthe recipe, and using what the recipe imported --
 not good.

 Are you sure about not using PIL (if even indirectly)?

Now that i think about it again, I think MPL makes some optional use
of PIL -- that's probably it.

 An idea how to tweak the MPL recipe to only pull in the backend we
 need? is there a way to pass options to he recipes?

 I hope Guido doesn't mind that I've borrowed his time machine. Support for 
 this was added in py2app 0.7:

 - Smarter matplotlib recipe, it is now possible to specify which backends 
 should
   be included. Issue #44, reported by Adam Kovics.

this is nice -- thanks!

 4) Ipython is getting pulled in my Matplotlib too:

 That should be fixable by excluding iPython.

I'll give that a shot.

thanks,
 -Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] app won't quit?

[Chris Barker - NOAA Federal]

On Tue, May 28, 2013 at 5:33 AM, Charles Hartman co...@conncoll.edu wrote:
 When I updated my app, I switched from the deprecated wx.PySimpleApp, which
 had the right default behavior on Mac, to wx.App, which apparently doesn't.

hmm -- I'm pretty sure that PYSipleApp is deprecated because it
doesn't actually do anything -- though it way chance a default or two.
One to look at is crating the app:

app = wx.App(True) will create an extra wx.Frame to capture stout.

app = wx.App(False) will not, and will not re-direct stdout.

 (The docs say You should normally exit the main loop (and the application)
 by deleting the top window.  What's normal for a Windows user would
 baffle my Mac users, and vice versa—but never mind.)

yup -- and wx follows the Windows/GTK conventions here, so you have to
kludge a bit to get proper Mac behavior

  I see I can call
 wxGetApp().ExitMainLoop.  But in response to what?  What is the event sent
 by the Mac keyboard or menu Quit command?

I'm still a bit confused -- if you build an app the regular wx way,
and it works right on Windows and Linux, then you should get an app
that goes away when you want it to stay alive, not the other way
around -- so I would expect you to need to figure out how to keep it
alive. IIUC, the way to do that is to create a dummy wx.Frame -- it
will keep the app alive, and give you a menu bar. See this SO thread:

http://stackoverflow.com/questions/2934435/how-to-change-the-osx-menubar-in-wxpython-without-any-opened-window

  Binding to wx.EVT_CLOSE doesn't seem to do anything.

where are you binding that? to the Frame? It's usually a wx.frame event.

Take a look at this:

http://wiki.wxpython.org/Optimizing%20for%20Mac%20OS%20X

Which does not address the question at hand, but may address other
questions...And if/when  you find a solution it would be great if  you
would add it to that page!

-Chris



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] [OT] advice on distributing for different OSs

[Chris Barker - NOAA Federal]

On Mon, May 27, 2013 at 1:23 AM, Ronald Oussoren ronaldousso...@mac.com wrote:

 It's unlikely that support for external dependencies will improve a lot
 in the near future unless someone does the work and provides a clear and
 usable specification, preferably with an implementation.

well, Gattai may be a good start

http://sourceforge.net/projects/gattai/

Not sure how much use it's had -- Kevin hasn't promoted it much. But
we're using it for a couple projects...

 A major problem for this is that external dependencies aren't much of
 a problem on Linux, most OSS C/C++ libraries are available from the
 repositories of the major Linux distribution (or add-on repositories). Because
 of this a major group of Python users doesn't notice the problem, and hence
 is less likely to work on a solution.

True, though it's not so much that it isn't an issue on LInux, as that
the distros have built-in tools to address those issues. But same
result.

 IMHO the best way forward is to build a solution for OSX, and only then try to
 generalize that with support for Windows and Linux.

agreed, and maybe not bother.

It might be worth looking at what Chris Gohlke does -- he builds a
heck of a lot of packages for Windows -- maybe he's got something
that's worth porting -- or maybe porting the API of.

 BTW. There is a tool that does have decent support for external dependencies:
 buildout.

I had forgotten about that -- maybe I'll take another look.

In any case, I think the order of operations is:

1) Figure out HOW we want to build binary packages -- i.e shared vs
static, where to install if shared, etc.

2) Develop/ adapt etc an automated way to build the packages.

3) worry about distribution of packages -- maybe wheels are it, or a
simple binary format like conda, which looks like it's BSD licensed,
and nice and simple.

I'm still working on (1) secondarily on (2)

The trick is to support regular install in site-packages, virtualenv,
and develop mode.

develop mode has me stumped at the moment -- at least being able to
do it in a way that shares dylibs between python packages..

-Chris








-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] app won't quit?

[Chris Barker - NOAA Federal]

Just found this:

http://wiki.wxwidgets.org/WxMac-specific_topics#When_to_close_the_program

maybe it will help.

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] app won't quit?

[Chris Barker - NOAA Federal]

On Tue, May 28, 2013 at 9:11 AM, Charles Hartman co...@conncoll.edu wrote:
 Thanks, Chris.  My app has a wx.Frame (subclassed, of course).  It's there
 that I've tried Binding EVT_CLOSE, but a breakpoint in the method I find is
 never reached at all, including when I use menu or keyboard to Quit.  On way
 I've tried is this snippet I got from wxPyWiki.  (The line that purports to
 add an Exit item to the File menu does not in fact do that.  Mac still keeps
 Quit in the MyApp menu.)

right -- wx tries hard to make you app more Mac-like by moving menu
items around. If a menu item has ID ID_EXIT, it will get moved, maybe
also if it is called exit or quit. But you want that, yes?

 item = self.fileMenu.Append(-1,'Exit','Terminate the program')
 self.Bind(wx.EVT_MENU, self.OnClose, item)
 if wx.Platform==__WXMAC__:
 wx.App.SetMacExitMenuItemId(item.GetId())

 This doesn't work either; OnClose() is never reached.

This is odd, but a few pointers. Try:

item = self.fileMenu.Append(ex.ID_EXIT,'Exit','Terminate the program')
self.Bind(wx.EVT_MENU, self.OnClose, item)
## this shouldn't be needed if you use the ID above.
 if wx.Platform==__WXMAC__:
 wx.App.SetMacExitMenuItemId(item.GetId())

I think you're going to need to put together a sample app. The
enclosed works. (I'd like to add the multiple-frame, app stays alive
thing, though...)

Oh, and you may want to try the Widget Inspection Tool -- it may
show you something.

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov


MacApp.py
Description: Binary data
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] [OT] advice on distributing for different OSs

[Chris Barker - NOAA Federal]

On Fri, May 24, 2013 at 2:10 AM, DavidWorrall v...@avatar.com.au wrote:
 maybe you'd like to help build one?

 mmm tempting. I'm moving continents ATM so it will have to wait a bit.

Who knows how much time I'll find for this, but my goal is to set up a
system (probably a gitHub project), and then others will be able to
contribute build scripts for particular packages. I'll certainly
annouce that effort when there is something to see...

If I can get this in place, I'm hoping that it will, in fact, be
easier to build new package by using this system that doing it from
scratch by hand, and once you've done it, why not contribute it back?

-Chris



 Enthought's offerings, for example. They seem pretty slick,

 When one installs their Canopy on the Mac, for example, they impose
 themselves on the Terminal prompt:

 (Canopy 32bit) drwIntel-6:~ drw$

you're kidding! Their installer messes with the prompt settings in
.bash_profile or somewhere? that really is too much! (I agree it's not
fatal, but WTF?)

 It's got the feel like Apple's own approach: take complete control of
 customer's computer/phone/etc
 Perhaps after years of this I'm ready to move to Linux.

I know the feeling...

-Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Advice wanted on dependency building...

[Chris Barker - NOAA Federal]

On Thu, May 23, 2013 at 12:45 AM, Samuel John pyt...@samueljohn.de wrote:

 I am from the homebrew team and passionate python lover. I can almost feel
 your pain :-)

Thanks for joining the discussion -- really great to have a
homebrew-familiar person to discuss with.

However, and please to correct me if I'm wrong, but my understanding
of the goal of homebrew (and macports, and fink [anyone still use
fink?] ) is to make it easy to build and run stuff on your system, and
indeed, in a way that is optimized for your system (macports, at least
has a bunch of use flags you can set that will customize the build the
way you like it).

On the other hand, what I'm talking about here is supporting people
that want to:

Distribute binary packages that support:
  - installing on older OS versions (and maybe different
architectures) machines than the developer is running.
  - using those packages with Py2app, to distribute apps that will run
on older machines and OSs.

I _think_ that homebrew's goals don't support that. I know homebrew
supports an option to build universal (i386+x86_64) binaries, but:
  a) not all formulae support that -- in general, it's not well tested
  b) I don't think it will build with an older sdk, which you'd  need
to support the above.

In fact, on my machine (64 bit, OS-X 10.7), I'm sort-of-running
homebrew, but it only partially works because I've got XCode 3
installed -- and it keeps telling me I should upgrade. I haven't
upgraded XCode, because I haven't figured out how to get XCode 4 to
build the binaries I need (Or needed, it may be the PPC support that
I've lost, and I guess I can dump that now...)

Anyway, if homebrew could support the goals above, it may be a good
way to go to solve the problems at hand.

 Some things install nice with pip, but others don't. That is why I started
 to maintain a separate tap for additional homebrew python  formulae
...
 These formulae re-use and depend on other software
 built with homebrew (for example suite-sparse from homebrew/science,
 libpng).
 See https://github.com/samueljohn/homebrew-python if you like.

cool -- very nice!

 With our recent kickstarter supported Mac Minis, we plan to build and
 provide binary bottles for all our packages.
 Perhaps that is a good starting point?

If those binary bottles support older OS versions (more or less, the
oldest one that Apple is currently supporting -- I think that's 10.6
now), then yes, that could be a way to go.

 Homebrew works bests if installed at `/usr/local` because of the paths to
 other libs.

yup -- I can imagine! And I'm fine with homebrew in usr/local, but I
don't want something someone installs specifically for MacPython
(outside of homebrew) stomping on it.

 I am currently making Python 2.x and 3.x support in homebrew possible and
 simplifying how to install python software that provides a setup.py.

Question:

Does homebrew put Python in usr/local? and give you a regular old
unix-style install? Or do you get a proper Mac Framework install
(wherever it puts it). I guess the key question is can you use it to
develop proper desktop apps, and use py2app to make re-distributable
app bundles?

If so, and if it can support older machines with binaries, then maybe
we could build MacPyton on top of it (or with it).

But the key issue is if the goals of the homebrew project align with
the goals I outlined above.

Thoughts?

-Chris




-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] [OT] advice on distributing for different OSs

[Chris Barker - NOAA Federal]

On Wed, May 22, 2013 at 11:49 PM, DavidWorrall v...@avatar.com.au wrote:

 I've been developing in Python on Mac's since b4 OSX and I have to give a
 workshop on the other side of the world in a (networked) non-OSX university
 lab (Windows, I think).

 Now I know dependencies are one of python's strengths,

no, it's not! I think dependencies are still kind of a nightmare with
Python. pip and pypi do a pretty good job with pure-python packages,
and an OK job with compiled-with-no-other-dependencies packages, but
packages that have other dependencies are a pain - python provides no
support whatsoever for that.

  it got me to wondering if there are some angels out there
 who support a downloadable collection of useful tools for various versions
 that python on OSX, Linux and Windows OSs that members of this group would
 recommend.

Christoph Golke is one such angel for Windows, and Pyton(x,y) and
PyWin (or something like that) are other all-in-0ne free distributions
for Windows. Nothing that I know of (free and open) for the Mac --
hence my note -- maybe you'd like to help build one?

 2.7.x seems the most viable Python. My orientation is scientific with an
 added emphasis on sound.

 I've looked at Enthought's offerings, for example. They seem pretty slick,
 but don't know what corporate dependencies I might be inadvertently
 buying into in adopting their builds.

Enthought or Anaconda are the two commercial offerings I know of. And
they are pretty good options, actually.

I don't know the downsides. For y part, I dn't use them, but maybe I
should. A few years back I tried Enthought when I needed to get some
Windows boxes up and running quickly. IN that case, I found that EPD
installs and is configured for MinGW, rather than the MS compiler --
and, it turns out, didn't work for compiling some custom extensions I
needed. Honestly, when it barfed on me, I dropped it and moved on,
without hardly any debugging time -- so it may have been a trivail
fix.

So the only issue I know if is that EPD used MinGW, rather than the MS
compiler -- don't know if that's a problem, though. I suspect Anaconda
os the same.

 Any thoughts/recommendations- or suggestions of a more appropriate forum to
 ask this - would be much appreciated.

with your science focus, you may try the scipy list, or the scientific
python LinedIn discussion group. But for Mac-focuses questions, this
is a good one.

-Chris



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Advice wanted on dependency building...

[Chris Barker - NOAA Federal]

On Wed, May 22, 2013 at 11:53 PM, Ronald Oussoren
ronaldousso...@mac.com wrote:
 I'm using the
 system zlib -- is that a bad idea? Should I build it too, to make sure
 it matches the rest of it?

 (I do want the binaries to run anywhere the binary Python I'm using runs)

 It depends on the library.

OK -- it would be nice to have rule to follow, but I guess that
decision should be made for each particular lib.

 I agree w.r.t. homebrew and macports, but it would be nice if 'pip install' 
 would work with your system with minimal changes to the pip configuration 
 (e.g. just add ... to your piprc and then 'pip install foo' will install a 
 binary from the repo instead of building the binaries itself).

yes -- it sure would -- though this is enough to do without trying to
hack on pip as well

 Yeah, and he never gave anyone else permission to push to it...

 I wouldn't have done that either until the someone else has a proven 
 trackrecord (both in providing usable binaries and in being known in the 
 community).

well, when I say anyone else, I mean anyone else -- I, and a few
others regularly contributed, but it involved sending it to him, and
hoping he'd find the time to put it up...So if I do this, I'd like to
have at least the option of a handful of folks contributing directly.

 But if we put the shared libs in amore central location, then all your
 virtual-ens could use the same ones, yes?

 Yes. It would make it harder to switch library versions, but not by much.

hmm -- this is getting tricky for me to wrap my head around -- could
we make it so a pip install inside a virtual env would install a
dependency in the main python? Or would you have people install the
libs outside of the virtualenv first, if they didn't want multiple
copies ?

 Uninstall can be a problem with that, you'd have to refcount installed files 
 to ensure that libraries are only removed when the last user is uninstalled. 
 I don't know if the installation format used by pip supports having two 
 packages that install the same file.

and I don't want to write that code anyway ;-)

 This can be worked around with fake PyPI packages that only install the 
 shared libraries and have the real packages depend on that (that is a 
 macbins-libpng package with libpng.dylib and have the Imaging package 
 depend on that).

I like that idea -- and It looks like that's how Anaconda deals with it.

 /Library can be used, we'd just have to pick a name that Apple is unlikely to 
 use.

I think it should go in /Library/Frameworks/Python somewhere, helps
the uninstall issue -- if folks clear that out, they won't have
anything left behind.

 I'm probably atypical, but my main account doesn't have admin privileges. It 
 would suck if I'd have to use sudo to install.

How do you install the python from Python.org? Im just thinking we
should match that...

 The @loader_path option you mentioned in a followup e-mail could help there. 
 That way the shared libraries can be installed in a fixed location relative 
 to sys.prefix, while still supporting virtualenvs. You wouldn't be able to 
 share shared libraries between python versions or virtualenvs, but that's not 
 really a problem (disk space is cheap).

That may be the way to go.


 Any idea what the time scale is on this?

 Before Python 3.4 is out, which means sometime this summer.

OK -- I figure Ill wait until it's there, and then try it out.


 Have the pip folks made any commitment at all to supporting binary
 installs? That's a big missing feature.

 Yes, through wheels. The development branch in pips repo 
 (https://github.com/pypa/pip/tree/develop/pip) contains support for wheels 
 (both creating and installing), although AFAIK installation of pips requires 
 a command-line argument at the moment because wheel support is experimental 
 at this point.

fair enough -- have you looked into the universal binary issue at all?
easy_install was always getting confused by universal binaries...

 I'll provide mental support at the least, and hope to do more than that but 
 don't know if I can do that time-wise.

You've provided an enormous amount already!

 If wx is hard to package it would be a good stress test of the tools, even if 
 you'd end up not distributing the binaries :-)

yup -- but I'm still not sure if I want to deal with it! -- we'll see.
Maybe Robin would be interested in supporting this shared lib system
if we do get to that.

I'm thinking of setting up a gitHub project for this..I'll let you all
know if/when I do.

-Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: 

[Pythonmac-SIG] Static Linking...

[Chris Barker - NOAA Federal]

As a side note to the main thread about dependencies:

How can  I static link?

Ive struggled for literally years to get gcc to statically link, but
it tries really hard to dynamically link instead. I have written way
too many scripts that move or re-name dynamic libs temporarily while
building, then put them back after.

Then a colleague of mine showed me the really neat trick -- pass the
paths to the libs themselves through to gcc with extra_objects
keyword in the Extension object, like so:

extra_objects = [libhdf5.a, libhdf5_hl.a, libnetcdf.a]

extensions = [Extension(netCDF4,
sources,
libraries=libs,
include_dirs=inc_dirs,
extra_objects=extra_objects,
)]

very nifty -- works like a charm.

However, when I do this, I had to re-write part of the setup.py --
actually, making it far more simple -- in this case, there was a lot
of machinations finding the libs...

But Ideally, Id ;like to build a semi-arbitrary extension with static
linking while using the existing setup.py. Is there a way to
minkey-path the setup, so I can use the existing one, but re-shuffle
it some in place before the actual build occurs?

-Chris




-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] Advice wanted on dependency building...

[Chris Barker - NOAA Federal]

Hey folks,

I'm looking for advice, and maybe even some consensus among the
MacPython community, on how to build and distribute packages with
non-python dependencies.

As we all know, a number of Python packages require libs that are used
outside of python itself. These libs fall into (sort of) what I would
call two catagories;

1) general purpose libs used by multiple python packages: libpng, freetype, etc.
 (I'm still confused on why Apple doesn't provide all these --
particularly libpng -- what's up with that?)

2) More specific libs, likely only used by a single python package --
netcdf, proj.4, etc.

Users also fall into two categories:

1) Folks that do Python development on OS-X much like Linux, etc --
these folks are likely to use macports or homebrew, or are used to the
.configure, make, make install dance. We don't need to do anything to
support these folks -- pip install generally works for them.

2) folks that want to use a Mac like a Mac, and people that develop
for those folks --  these people need binary installers, and may want
to be able to use and deploy either packages or applications (Py2app)
that will run on systems older than the one developed on, or want
universal builds, or ???
  - These are the folks I'd like to support, but I'm still unsure as
to how best to do that.

Way back when Bob Ippolito maintained a repository of binary packages
for the mac -- it was a great resource, but he's long since moved on
to other things.

We kind of get away with it because a number of major package
maintainers have done a good job of providing binaries themselves
(wxPython, numpy/scipy/matplotlib), but others fail to do so (PIL).
Plus some of us have minor packages that we want to distribute.

I'd like to put together an archive, much like Bob's was, or like
Christoph Gohlke's one for Windows
(By the way -- that one is HUGE -- I have no idea how he keeps it up!
http://www.lfd.uci.edu/~gohlke/pythonlibs/)

But with or without that archive, I still need to build the darn
things. So now on to the question:

How should the dependencies be distributed?

1) They should be built to match the Python binary being targeted
(honestly, I think that's now only the Intel 32-64 bit ones -- PPC
machines, and pre 10.6, are getting really rare...)

2) Static or dynamic?

IIUC, most successful binary packages for the Mac have relied on
statically linking the dependencies -- this works, and is pretty
robust. However, it can be kind of a pain to do (though I've finally
figure how to do it more reliably!). Also, it seems like a waste to me
for packages that use common dependencies -- how many copies of libpng
do I really want linked into my single instance of Python at run time?

But if dynamic, where do you put them? We'll still want to ship them
with the binary, so people have a one-click install. I don't think we
want to install them into a standard location, like /usr/local, as
that could stomp on something else the user is doing. So:
 - Do we put the in the Python Framework, say in:
/Library/Frameworks/Python.framework/Versions/2.7/lib
 - This make some sense, but then you couldn't share them between,
say, python 2.7 and 3.3 (and however many other versions...
  - Do we create a new Framework, say:
/Library/Frameworks/PythonDeps.framework and put them all there? But
this may confuse things for different deployment targets.

If we go one of these routes, would we have a separate installer for
the libs, and all the other installers would depend on that? Or would
each installer put a copy of the libs it needed into the common
location, maybe writing over one that's already there (which should be
OK -- it should be compatible, or have a different version number,
etc.)

Note that I've used the term we here ;-)  I'm hoping that others
will join me in following a convention and getting stuff out there,
but even if not, I'd love feedback on how best to do it.

By the way, the other goal is to build scripts that do the builds the
way we need for various libs, packages, etc, so that it's easy to do
it all when new builds are required...
(maybe use gattai? -- http://sourceforge.net/projects/gattai/)

Feedback please!!

-Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Advice wanted on dependency building...

[Chris Barker - NOAA Federal]

Thanks Ronald,

On Wed, May 22, 2013 at 2:53 PM, Ronald Oussoren ronaldousso...@mac.com wrote:

 To move back onto topic, not relying on unix-level libraries in OSX is in a 
 good thing as it makes it easier to support multiple OSX versions with a 
 single set of binaries.

hmm -- I figured if it was a system lib, it should work on whatever
system It's running on. For example, I'm working right now on the
netcdf4 lib -- it required hdr5, which requires zlib. Im using the
system zlib -- is that a bad idea? Should I build it too, to make sure
it matches the rest of it?

(I do want the binaries to run anywhere the binary Python I'm using runs)


 Except for a number of more complicated libraries (such as PIL/Pillow) when 
 using universal binaries (when using 'pip install', homebrew/macports/... 
 have their own mechanisms for building).

right -- Universal libs are not well supported by those systems -- but
that's the power users problem!

 2) folks that want to use a Mac like a Mac, and people that develop
 for those folks --  these people need binary installers, and may want
 to be able to use and deploy either packages or applications (Py2app)
 that will run on systems older than the one developed on, or want
 universal builds, or ???
  - These are the folks I'd like to support, but I'm still unsure as
 to how best to do that.

 It would be nice to have a set of binary packages, based on a reproducable 
 build system.

Exactly what I'd like to build!

 Way back when Bob Ippolito maintained a repository of binary packages
 for the mac -- it was a great resource, but he's long since moved on
 to other things.

 The binary packages that Bob maintained had IMHO two major problems:

 1) The largest problem is that the packages were AFAIK created ad-hoc (Bob or 
 some other contributor did the magic incantations to build library 
 dependencies)

Yeah, and he never gave anyone else permission to push to it...

 2) The packages were Installer.app packages. The current state of the art for 
 development/project environments is to use virtualenv or buildout to create 
 separated python installations and install all project depedencies there 
 instead of the global site-packages directory. That's not something that's 
 easily supported with Installer.app packages.

It was the way to go at the time, but I agree a binary format that
supports virtualenv would be great.

 do I really want linked into my single instance of Python at run time?

 As long as the libpng state isn't shared static linking isn't really a
 problem.

good to know, but somehow it still offends my sensibilities

 Dynamic linking has at least two disadvantages:

 1) Relocation of the installation prefix is harder due to the way the dynamic 
 linker on OSX looks for libraries:

yeah -- that is a pain.

 The header is easily updated using macholib, but that makes installation
 harder and isn't supported by the standard packaging tools (easy_install
 and pip)

But if we put the shared libs in amore central location, then all your
virtual-ens could use the same ones, yes?

 2) The primary use case for dynamic linking is to share dylibs between 
 extensions, and when those extensions are in different PyPI packages the 
 packaging story gets more complicated. The easiest workaround is to ignore 
 sharing dylibs and still bundle multipe copies of libpng if two different 
 PyPI packages both link with libpng.

when you say bundle, do you mean static link? Or just package up the
dylib with the bundle, which is what i was thinking -- each package
installs the libs it needs, which may or may not already have been
installed by another package -- but so what?

And I expect the number of folks building packages will be fairly
small, so one builder would one have to build one set of dylibs.

 But if dynamic, where do you put them? We'll still want to ship them
 A new framework isn't necessary. There are three locations that could easily 
 be used:

 1) A directory in Python.framework, for example 
 /Library/Frameworks/Python.framework/Frameworks

That makes sense to me.

 2) A directory in /Library/Python, for example /Library/Python/Externals

that feels a bit lke Apple's turf, but what do I know?

 3) As 2), but in the users home directory (~/Library/Python/Externals)
 The latter is the only one where you can install without admin privileges.

But we put the python binaries  in /LIbrary/Frameworks -- it seems we
should do the same with libs...


 The folks over on distutils-sig are working towards support for wheels (PEP 
 427, http://www.python.org/dev/peps/pep-0427/) at least in pip and 
 distribute/setuptools and possibly in the stdlib as well (for 3.4). It would 
 be nice if the OSX package collection would be in wheel format, that would 
 make it relatively easy to install the packages using the defacto standard 
 tools.

Any idea what the time scale is on this?

 What I haven't looked into yet is how easy it would be to configure pip to 
 look for 

Re: [Pythonmac-SIG] Advice wanted on dependency building...

[Chris Barker - NOAA Federal]

I just poked a bit into the Anaconda Python distribution. their
packages are simple tarballs, but I think they have a dependency
management system of some sort.

They deliver the dependencies as separate packages (tarballs), one for
each lib. It looksl ike it all gets unpacked inot a sinlgle dir (in
/opt), and an example python extension is built like this:

$ otool -L netCDF4.so
netCDF4.so:
@loader_path/../../libnetcdf.7.dylib (compatibility version 10.0.0,
current version 10.0.0)
@loader_path/../../libhdf5_hl.7.dylib (compatibility version 8.0.0,
current version 8.3.0)
@loader_path/../../libhdf5.7.dylib (compatibility version 8.0.0,
current version 8.3.0)
@loader_path/../../libz.1.dylib (compatibility version 1.0.0, current
version 1.2.7)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 
1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 111.0.0)


I don't know how to get that @loader_path thing in there, but this
seems like a reasonable way to do it (though I guess it wouldn't
support virtualenv...)

-Chris



On Wed, May 22, 2013 at 3:46 PM, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
 Thanks Ronald,

 On Wed, May 22, 2013 at 2:53 PM, Ronald Oussoren ronaldousso...@mac.com 
 wrote:

 To move back onto topic, not relying on unix-level libraries in OSX is in a 
 good thing as it makes it easier to support multiple OSX versions with a 
 single set of binaries.

 hmm -- I figured if it was a system lib, it should work on whatever
 system It's running on. For example, I'm working right now on the
 netcdf4 lib -- it required hdr5, which requires zlib. Im using the
 system zlib -- is that a bad idea? Should I build it too, to make sure
 it matches the rest of it?

 (I do want the binaries to run anywhere the binary Python I'm using runs)


 Except for a number of more complicated libraries (such as PIL/Pillow) when 
 using universal binaries (when using 'pip install', homebrew/macports/... 
 have their own mechanisms for building).

 right -- Universal libs are not well supported by those systems -- but
 that's the power users problem!

 2) folks that want to use a Mac like a Mac, and people that develop
 for those folks --  these people need binary installers, and may want
 to be able to use and deploy either packages or applications (Py2app)
 that will run on systems older than the one developed on, or want
 universal builds, or ???
  - These are the folks I'd like to support, but I'm still unsure as
 to how best to do that.

 It would be nice to have a set of binary packages, based on a reproducable 
 build system.

 Exactly what I'd like to build!

 Way back when Bob Ippolito maintained a repository of binary packages
 for the mac -- it was a great resource, but he's long since moved on
 to other things.

 The binary packages that Bob maintained had IMHO two major problems:

 1) The largest problem is that the packages were AFAIK created ad-hoc (Bob 
 or some other contributor did the magic incantations to build library 
 dependencies)

 Yeah, and he never gave anyone else permission to push to it...

 2) The packages were Installer.app packages. The current state of the art 
 for development/project environments is to use virtualenv or buildout to 
 create separated python installations and install all project depedencies 
 there instead of the global site-packages directory. That's not something 
 that's easily supported with Installer.app packages.

 It was the way to go at the time, but I agree a binary format that
 supports virtualenv would be great.

 do I really want linked into my single instance of Python at run time?

 As long as the libpng state isn't shared static linking isn't really a
 problem.

 good to know, but somehow it still offends my sensibilities

 Dynamic linking has at least two disadvantages:

 1) Relocation of the installation prefix is harder due to the way the 
 dynamic linker on OSX looks for libraries:

 yeah -- that is a pain.

 The header is easily updated using macholib, but that makes installation
 harder and isn't supported by the standard packaging tools (easy_install
 and pip)

 But if we put the shared libs in amore central location, then all your
 virtual-ens could use the same ones, yes?

 2) The primary use case for dynamic linking is to share dylibs between 
 extensions, and when those extensions are in different PyPI packages the 
 packaging story gets more complicated. The easiest workaround is to ignore 
 sharing dylibs and still bundle multipe copies of libpng if two different 
 PyPI packages both link with libpng.

 when you say bundle, do you mean static link? Or just package up the
 dylib with the bundle, which is what i was thinking -- each package
 installs the libs it needs, which may or may not already have been
 installed by another package -- but so what?

 And I expect the number of folks building packages will be fairly
 small, so one

Re: [Pythonmac-SIG] py2app questions..

[Chris Barker - NOAA Federal]

Ronald et al,

As matplotlib seems to be responsible for bringing eveything else in,
I'm trying a different tack:

1) I've removed many of the recipes from my p2app distribution,
notably teh matplotlib one. So now the only recipe getting run is wx.

2) I know that matplotlib isn't going to work right, as there are
issues with matplotlib data, etc. So I've tried to remove it by adding
it to excludes. However, it's getting included anyway, in the
site_packages zip file. (but doesn't work...)

But moving on...

Ive added ['matplotlib'] to packages.

Now I get it included, in full, in Resources/lib/python2.7, and non
longer in the site_packages zip, and the app works fine.

the matplotlib package is 64MB though, so it would be nice to trim it
down, but this isn't bad, and the total package is now 134MB, rather
than the 210MB I did have.

So I suggest that the matplotlib recipe should:

- remove matplotlib from the site_packages zip

- install the matplotlib package in it's entirety (though maybe strip
out the *.py files, and things like tests, etc.)

- not run matplotlib through modulegraph -- whatever the user is
actually using (numpy, etc) is probably imported elsewhere anyway.
(though maybe including numpy would make some sense...)

I hope this helps others in the future in any case.

-Chris








On Fri, Apr 12, 2013 at 1:47 PM, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
 OK,

 I've run py2app with --xref. I've enclosed the html output.

 Again, this app uses:

 wxPython
 numpy
 matplotlib

 (and a few other stdlib packages...)

 I've learned a few things from this.

 1) this is odd:
   right near the top, I see:
  prescript.py
  imports: Image
   that's the prescript for the PIL recipe -- Im not using PIL, it
 seems it's runnign nthe recipe, and using what the recipe imported --
 not good.


 2) do I need all of Carbon?
 Carbon
 imports: warnings
 imported by: Carbon.AE Carbon.Appearance Carbon.AppleEvents
 Carbon.CarbonEvents Carbon.ControlAccessor Carbon.Controls Carbon.Ctl
 Carbon.Dialogs Carbon.Dlg Carbon.Dragconst Carbon.Events Carbon.Evt
 Carbon.File Carbon.Files Carbon.Menu Carbon.Qd Carbon.QuickDraw
 Carbon.Res Carbon.TextEdit Carbon.Win Carbon.Windows EasyDialogs
 aepack aetools macostools macresource plistlib

 I'm guessing py2ap uses plistlib, or something...

 3) Matplotlib has multipel back-ends -- that's why I'm getting TK
 stuff (and from there, Carbon?):
FileDialog
imports: Dialog Tkinter fnmatch os
imported by: matplotlib.backends.backend_tkagg

 An idea how to tweak the MPL recipe to only pull in the backend we
 need? is there a way to pass options to he recipes?

 4) Ipython is getting pulled in my Matplotlib too:

 IPython
 imports:
 
 IPython.zmq matplotlib.sphinxext.ipython_directive

 which explains the zmq.so

 ( and a lot of other stuff -- iPython pulls in a lot )

 5) It looks like Image is getting pulled in a couple places:
 ...
  docutils.parsers.rst.directives.images docutils.writers.html4css1
 prescript.py scipy.misc.pilutil

 docutils, prescript, and scipy (not sure why scipy is pulled in yet, I
 removed that dependency...)

 6)OpenGL
 imported by: IPython.lib.inputhookglut 

 so that's getting pulled in by IPython, which is pulled in by MPL... ( I 
 think )
 (wow! OPenGL sure has a lot of modules!)

 7) bsddb seems to be recusively importing itself...

 bsddb
 imports: UserDict _bsddb bsddb.dbutils collections os warnings weakref
 imported by: bsddb.db bsddb.dbutils dbhash

 bsddb.db
 imports: _bsddb bsddb
 imported by: bsddb.dbutils

 bsddb.dbutils
 imports: bsddb bsddb.db time
 imported by: bsddb

 

 OK, I'm getting bored. A lot of this is really caused by Matplotlib --
 which make some sense, it's been designed to be a developers tool (or
 at least to be used interactively), with all sorts of options,
 determined at run-time.

 Is there a way to turn off a recipe other than removing ot from my
 py2app install?

 This is making me think that the MPL recipe should pull in the MPL
 package, but not scan it for dependencies...

 Still not sure about PIL -- but I wouldn't be surprised if MPL is
 involved somehow!

 -Chris



 --

 Christopher Barker, Ph.D.
 Oceanographer

 Emergency Response Division
 NOAA/NOS/ORR(206) 526-6959   voice
 7600 Sand Point Way NE   (206) 526-6329   fax
 Seattle, WA  98115   (206) 526-6317   main reception

 chris.bar...@noaa.gov



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] py2app questions..

[Chris Barker - NOAA Federal]

On Thu, Apr 11, 2013 at 10:50 PM, Ronald Oussoren
ronaldousso...@mac.com wrote:
 On 11 Apr, 2013, at 23:50, Chris Barker - NOAA Federal 
 chris.bar...@noaa.gov wrote:

 *** using recipe: virtualenv ***
 *** using recipe: sip ***
...

 It looks like the recipes for ALL of the packages I have installed are
 being run -- a bug perhaps?

 That's not a bug, all recipes get called on every build and each one checks 
 if it actually has to do something (mostly by checking for the presence of 
 modules in the dependency graph).

hmm -- maybe a re-write of that message to something like checking
recipe: something.

But anyway, as far as I can tell, I'm getting all the packages there
is a recipe for that I have installed. Or certainly a bunch of extras.

I'll poke into the dependency graph and see if I can see what's going on.

-Chris




-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] py2app questions..

[Chris Barker - NOAA Federal]

First: Ronald, thanks for keeping py2app up to date!

The good news: I just ran a recent py2app on an older app of mine, and
it all worked out of the box.

However, the resulting bundle is HUGE. A lot of this is inevitable,
I'm using a universal build, and some big packages, but there seems to
be some room for improvement:

The app  in question is using:

wxPython
numpy
a tiny bit of scipy
matplotlib

So it's going to be big!

Numpy, scipy and matplotlib all have a lot of intertwining modules,
many of which get imported whether you need them or not, so probably
the best one can do is include them all (more on that later)

However, I'm getting a couple packages that I have no idea why:

OpenGL
email
zmq

hand-removing them from the bundle doesn't break anything.

I'm wondering if their recipes are getting triggered by accident
somehow -- how can I tell how/why a particular package got included?

I'm also getting a number of *.so files that I don't understand --
some of the larger ones are:

_bsddb.so
_sqlite3.so
_imaging.so  (is that PIL?)

there are a LOT more, but it's had to know what they are from just the
names, and most are pretty small anyway  (except the wx ones that I
need and expect to be big...)

I understand that it's a goal of py2app to work out of the box
without needing to hand-tweak a lot to get it to work. This is a
worthy goal, and the recipes approach works great. However, it would
be nice if there was an alternate approach that made it easier to
build a more optimized package. One idea:

Py2app (and all the other stand-alone builders I've looked at) figure
out want to include from source code analysis. however, as it's pretty
common for packages to import stuff that may not be used a
particular app, you can get a lot of stuff you dontt need. For
instance, I'm pretty sure that PIL import tkInter. These imports are
often wrapped in an if clause or inside a function that may never get
called, but source code analysis isn't going to find all of those, so
the same thing to do is include it all -- resulting in bloated
packages.

I propose an alternative -- analysis of the app at run-time: The user
would run the app (maybe a test suite), then we'd take a look at
sys.modules and see everything that was actually loaded. This would
miss anything that wasn't exercised by the code you ran, but for most
cases, a test suite would bring in everything (comprehensive test
suites are hard to come by, but all it would need to do is test enough
to import every package it might use -- that's not a heavy lift).

This seems so easy -- am I missing something???

To support this, py2app would need a way to bypass the source code
analysis, and instead load a data file with the list of modules that
need to be included. Actually, as it sometimes takes a while to scan
teh code, it would be nice of py2app could optinally dump the results
of teh source code analysis, and be abel to re-load it later, rather
than needed to re-run.

1) Am I missing something as to why the run-time analysis wouldn't work ?

2) how hard would it be to patch py2app to load a module list, rather
than scan the source?

Thoughts??

-Chris






-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Good way for beginner to get started with Python?

[Chris Barker - NOAA Federal]

I'd second a couple others posting on this thread to set up the
environment for your friend if need be. I think it's a much better
idea to choose what tools, libraries, etc he should learn from by
criteria other than it comes with python out of the box.

A couple specific suggestions:

There have recently been published a couple different book that teach
Python to kids. I haven't looked closely at any of them but they've
been pretty well reviewed:

Snake Wrangling for Kids

Python for Kids - A Playful Introduction to Programming

Hello World!: Computer Programming for Kids and Other Beginners

If PyGame doesn't provide a nice complete binary installer for OS-X,
that might be a great contribution to the community.

As for IDE/Text editor -- definatly set him up with a real,
python-aware programmers editor -- Not TextEdit!

TextWrangler has less-than-idea python support, but it's a reasonable choice.

SublimeText2 is very nice (though only a trial version is available for free)

PyCharm has free class room and Open Source licenses that may be
applicable here.

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] py2app failure with framework build of 2.7

[Chris Barker - NOAA Federal]

On Thu, Apr 4, 2013 at 8:01 AM, Nat Echols nathaniel.ech...@gmail.com wrote:
 On Thu, Apr 4, 2013 at 5:46 AM, Ronald Oussoren ronaldousso...@mac.com 
 wrote:

 An alias mode build contains symlinks to the python files in your 
 application, and is therefore not a useful way to deploy.

 It's still not totally clear to me if this is really a drawback in my
 case.  The software distribution in question is a huge (~2GB) mess
 originally written for Unix systems, and the installation process is
 somewhat... inelegant.  Users have a choice of a) running a shell
 script which installs to a destination of their choice, and runs the
 py2app script at the end (after the new location is made permanent),

This should work well, and actually, issues with doing a proper
py2app bundle aside, may be the best way to do it. The point of Py2app
is to bundle up everything required into the app bundle, so that is it
one movable directory, hides teh pyton stuff from the user, and does
not rely on a particular pyton installation (i.e extra packages, etc).
But it sounds like in your case, you've got to install the whole pyton
environment anyway, along with all sorts of other stuff. So all you
need the app bundle for is to make a nice clickable icon. That's
exactly what I use alias mode for as well, though I've never tried to
give it to anyone else that way. Actually, I have -- I have set up a
setup.py script that works with py2app in alias mode (but not it
regular mode), then advised users to get the code installed, install
all the dependencies, then run py2app -A and build the alias really
what you are doing, except you are automating the rest of the install.

 or b) running a .pkg which installs in /Applications, which includes
 the pre-built .app file.  In the first case, I'm pretty certain the
 symlinks won't be a problem.  I'm not sure about the second - will
 packagemaker screw these up?  The original paths will be accurate but
 I have to move stuff around as part of the packaging process, and I
 have no idea what happens internally.

if it all gets put in the same places by the installation process, I
think it will work. But you never know until you try.

-Chris




-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Accessing .so files in BGE python scripts

[Chris Barker - NOAA Federal]

Hi,

Not sure what leap is, but maybe this will be helpful...

 This is sample of part of the LeapPython.so (.dynlib) I need to access in 
 Blender 2.66a Game Engine on my MacMini SnowLeopard 32 bit:
...

 This is the type of errors I am getting when there is a call like:

 __swig_destroy__ = LeapPython.delete_FloatArray


so this is SWIG-wrapped code -- are you doing the swig-ing, or are you
just suing something provided?

 AttributeError: 'module' object has no attribute 'delete_FloatArray'

 After looking at this type of error, what is the correct location to put the 
 LeapPython.so ( dynamic library ) so a Blender script can find it and access 
 the data on it? Or perhaps my .so file is of the wrong format?

What is LeapPython.so ? is that the python extension file (i.e do you
do import LeapPython) -- in which case, it needs to be on sys.path
somewhere -- not entirely sure where that would be with Blender, but
the same place as where you put *.py files.

However, if LeapPython.so is not an extension, but rather a library
called by the extension, then it needs to be linked in when the
extension is built. Check out the setup.py to see what's happening
there.

-HTH,
  -Chris




-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] 32+64 bit Intel PIL binary?

[Chris Barker - NOAA Federal]

Hi folks,

Has anyone built a 32+64 bit Intel binary for PIl? (to match the
Python 2.7 Intel build on python.org).

Russell Owen has a PIL-1.1.7-py2.7-python.org-macosx10.6.dmg

(http://www.astro.washington.edu/users/rowen/python/)

But it appears to only work right in 64 bit mode. I suspect the
dependencies are not all universal -- though I haven't dug into it.

This does remind me that it would be nice to have a home for binary
mac python packages somewhere (like Bob Ippolito's old repository)
Anyone have a good idea where to host such a thing?

-Chris



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] 32+64 bit Intel PIL binary?

[Chris Barker - NOAA Federal]

added note:

I found a universal jpeg binary here:

http://ethan.tira-thompson.com/Mac_OS_X_Ports.html

after installing that:

pip install pillow

seemed to work -- it's still missing CMS support, though -- which i
can live with.

It's still be nice to provide full-featured binaries for folks.

-Chris



On Thu, Dec 20, 2012 at 12:15 PM, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
 Hi folks,

 Has anyone built a 32+64 bit Intel binary for PIl? (to match the
 Python 2.7 Intel build on python.org).

 Russell Owen has a PIL-1.1.7-py2.7-python.org-macosx10.6.dmg

 (http://www.astro.washington.edu/users/rowen/python/)

 But it appears to only work right in 64 bit mode. I suspect the
 dependencies are not all universal -- though I haven't dug into it.

 This does remind me that it would be nice to have a home for binary
 mac python packages somewhere (like Bob Ippolito's old repository)
 Anyone have a good idea where to host such a thing?

 -Chris



 --

 Christopher Barker, Ph.D.
 Oceanographer

 Emergency Response Division
 NOAA/NOS/ORR(206) 526-6959   voice
 7600 Sand Point Way NE   (206) 526-6329   fax
 Seattle, WA  98115   (206) 526-6317   main reception

 chris.bar...@noaa.gov



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] bdist_mpkg question: python 3 support?

[Chris Barker - NOAA Federal]

Oops hit send by accident .


On Dec 17, 2012, at 9:57 AM, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:

 On Dec 17, 2012, at 1:34 AM, Ronald Oussoren ronaldousso...@mac.com wrote:



 You could port bdist_mpkg yourself, doing that should be too hard. That 
 said, bdist_mpkg creates an old package format that doesn't support some of 
 the more recent features of Installer.app (such as signed packages).

 Another alternative is to use the packaging tools provided with Xcode, you 
 will have to do more manually but will end up with a modern package format.

 Do you think it would be hard to update bdist_mpkg to support the new
 format? It is nice to have a simple, pure python, way to build a.

Binary installer.


 binary eggs and those don't require additional tools.

Binary eggs do require setup tools or distribute, though that's not
too heavy a lift.

But setup tools used to get all confused by Universal binaries--has
that been fixed? If not, it still may be easier to fix that than do a
bdist_mpkg update.

Chris



 Ronald


 -- Russell

 ___
 Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
 http://mail.python.org/mailman/listinfo/pythonmac-sig
 unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

 ___
 Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
 http://mail.python.org/mailman/listinfo/pythonmac-sig
 unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] bdist_mpkg question: python 3 support?

[Chris Barker - NOAA Federal]

 Do you think it would be hard to update bdist_mpkg to support the new
 format? It is nice to have a simple, pure python, way to build a.

 I don't know, I haven't looked into that yet (but will likely do so for the 
 python.org installers).  I don't even know if the new format is properly 
 documented, with some luck its a closed binary format that can only be 
 created using Apple's tools.

can those tools be called from a command-line, though? Requiring the
dev tools to be installed to build a binary is not a big limitation.

 I don't care too much about having something like bdist_mpkg because it has 
 only limited usefulness: installer.app has limited features (no uninstall, 
 very limited upgrade features), and it is hard to support virtualenv using 
 installer.app packages.

True -- but it was nice to have something folks were familiar with and
could just point and click on.

Ages agio we had a discussion about having a tool that could be
distributed with MacPython that could be associated with *.egg files
and install eggs properly -- so newbies could just point and click on
an agg. That would be nice, but in the end of the day, you're going to
need to learn a bit about installing packages if you're really going
to use Python anyway.

 Binary eggs do require setup tools or distribute, though that's not
 too heavy a lift.

 IIRC bdist_mpkg also uses setuptools, so that's not really a disadvantage 
 here.

I meant you need setuptool sor distribute to install binary eggs --
requirements for building installers are a non-issue.

 The real problem with binary eggs is that pip doesn't install them, and pip 
 seems to be the
 new hotness w.r.t. package management at the moment.

Indeed it does -- I hadn't realized it didn't install binary eggs -- I
guess it's been a while since I've tried that!

 There is some discussion about a new format (see 
 http://www.python.org/dev/peps/pep-0427/, but I'm not sure why that would 
 be better than eggs (other than that it isn't a setuptools egg).

It looks like it has some advantages -- but it's not there now, and
who knows if it ever will be...

 The packaging landscape for Python still sucks and that might not change 
 anytime soon.

:-(

 But setup tools used to get all confused by Universal binaries--has
 that been fixed? If not, it still may be easier to fix that than do a
 bdist_mpkg update.

 Setuptools works just fine with universal binaries, and always has.

it build binaries fine, but easy_install got confused when you tried
to install them.

 It does treat 'universal' like any other architecture though, which means it 
 doesn't understand
 that a binary egg with x86_64 only will work just fine when you are on a 
 x86_64 machine
 with a python framework that supports i386 and x86_64. Whether or not that is 
 a problem
 depends on your usecase.

It would be nice to suport that use-case, though it's ripe for
confusion for casual users.

But at least a couple years ago, if you build a binary egg with
setuptools with a universal Python, you'd get an egg that setuptools
would get confused trying to install -- I can't remember the details,
but often when a user tried to install it, easy+install would end up
downloading the source and trying to build it. IIRC, often it had, in
fact, successfully installed the binary, so you could kill the process
and have it work -- but that wasn't the least bit clear to the user.

I also have a vague recollection that you could fix that problem
simply be re-naming teh binary but my memory is hazy there.

It seems binary egg installation should be pretty easy, and it doesn't
look like the pip folks are opposed to the idea, so maybe we could add
that to pip, if distribute builds them properly anyway.

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Building a 32 bit framework build in a 64 bit system

[Chris Barker]

Ned,

Thanks for the detailed reply -- not sure when I'll be able to really
try this, but I'll let this list know how it goes when I do.

-CHB


On Tue, Oct 16, 2012 at 10:48 PM, Ned Deily n...@acm.org wrote:
 In article
 calgmxe+taozml2ftp8b6ao9grlyfgkaozgc4odv8ceexdd8...@mail.gmail.com,
  Chris Barker chris.bar...@noaa.gov wrote:
 I'm finding it a pain to force the Universal Python to 32 bit -- for
 building extensions, as well as running, etc. So I though maybe it
 would be nice to have a just plain 32 bit Intel build -- then I can
 use that to run and test all mystuff (I'm depending on 32 bit only C++
 code extensions), and also have something to re-distribute that
 doesn't carry around worthless (for my needs)  64 bit baggage.

 With reasonably current python.org Pythons, you can use the ARCHFLAGS
 environment variable to limit which archs are used by Distutils (and
 tools which use Distutils like easy_install or pip) to build C extension
 modules.  For example, to limit to just 32-bit Intel, you could use
 something like:

 ARCHFLAGS='-arch i386' easy_install psutil

 or
 export ARCHFLAGS='-arch i386'
 python2.7-32 setup.py install

 Poking through the READMEs, I'm having trouble figuring out how to
 build a 32bit-only python framework on a 64 bit system.
 --with-universal-archs values all have multiple builds (hence
 universal...).

 The Mac/README was revised and updated for the recent 3.3.0 release; at
 the moment, it has the most recent information.  While it was written
 for that release, most of the information applies to 2.7.x as well.

 http://hg.python.org/cpython/file/default/Mac/README

 or is it as simple as passing arch=i386 in to configure?

 Pretty much.   Here's a very simple configure for use with Xcode 4 and
 OS X 10.8 for a non-framework 32-bit-only build.   Adjust the deployment
 target as needed and for Xcode 3 I'd recommend using CC=gcc-4.2.

./configure CFLAGS=-arch i386 LDFLAGS=-arch i386 \
 CC=clang MACOSX_DEPLOYMENT_TARGET=10.8

 (I'll want to build a dmg installer too, but cross that bridge when I
 come to it...)

 Look at the readme for the installer build script (again, this is the
 more recent 3.3+ version):

 http://hg.python.org/cpython/file/default/Mac/BuildScript/README.txt

 NOTE: I'm running 10.7, and would like to use the latest XCode (4.2?),
 and am OK with the result only working on 10.7+ systems, though 10.6
 and above would be nice.

 Set the deployment target env variable to 10.6 or whatever version you
 need.  By the way, at the moment, the latest version of Xcode for 10.7
 and 10.8 is Xcode 4.5.1 available for free through App Store.app.

 There are some gotchas with the most recent versions of Xcode 4.  Among
 them are the elimination of the use of the /Developer directory; now
 things like SDKs are contained within Xcode.app itself.  You can find
 them using xcodebuild:

 xcodebuild -version -sdk macosx10.7 Path

 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Deve
 loper/SDKs/MacOSX10.7.sdk

 And, after installing/updating Xcode.app, you also need to install the
 Command Line Tools component of Xcode from Xcode - Preferences.  That
 installs things like clang, make, ld, and system include files into
 their conventional places within /usr.

 Good luck!

 --
  Ned Deily,
  n...@acm.org

 ___
 Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
 http://mail.python.org/mailman/listinfo/pythonmac-sig
 unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] permission of doc dir

[Chris Barker]

On Tue, Oct 16, 2012 at 3:16 PM, Ned Deily n...@acm.org wrote:

 which bug tracker? The main python.org one?

 Yes, please.

will do.

 I've done an extensive update for the recently released 3.3 version.  I 
 intend to backport some of the README and some of the Xcode 4 support, at 
 least, to 2.7 before the next maintenance release, which should be coming up 
 soon.  Lots to do!

great!, thanks for al your work on this.

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] permission of doc dir

[Chris Barker]

On Mon, Oct 15, 2012 at 5:13 PM, Ned Deily n...@acm.org wrote:
 Please open an issue on the bug tracker so we don't forget.  Thanks!

Done:

http://bugs.python.org/issue16256

-Chris



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] py2app unable to find cprocessors.so

[Chris Barker]

On Thu, Sep 13, 2012 at 1:53 AM, Ronald Oussoren ronaldousso...@mac.com wrote:

 Yea exactly, I have some smaller apps which are used for specific separate
 jobs (one has a simple gui and generates and gathers log files from the main
 app and zips them up should the main app ever fail to open for instance),
 the jobs are all to do with the main app and all use a sub set of code to
 the main app, so I put the apps in the Resources folder and symlink the lib
 folder so I can include them with only using a little extra disk space, but
 more importantly keeping the installer size down.


 That sounds like something that would be useful to support directly. I'll
 add it to the list of nice-to-have featuers, but don't know when I'll get
 around to looking into this.

That does sound cool  -- What do you have in mind exactly? One thing
Id like to be able to do is use py2app to build a Framework (not
sure if it would be a real OS-X framework that would contain all the
non-app-specific stuff, essentially a custom Python install, that I
could then use for a number of small apps. For instance, a number of
my apps use wxPython, numpy, scipy, matpotlib...

These are pretty darn huge packages. So If I have a three or four
small apps that ll use these, it would be great to have one bundle
that they share.

I'm imagining a multi-app kind of thing, you'd specify in setup.py the
handful of apps you want to build, py2app would see what the shared
dependencies were,a and build a bundle of those, then put the app
specific stuff in each individual app bundle. So you'd get one small
.app for each application, plus one bundle (of some form) that they
all depended on.

Similarly you could put the superset of everything that ll the apps
need in teh master bundle, and the individual apps would be tiny
stubbs.

Call it an app_collection, maybe?

Not that I'm volunteering to write it

-Chris






-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] py2app unable to find cprocessors.so

[Chris Barker]

On Thu, Sep 13, 2012 at 10:36 AM, Michael McCracken
michael.mccrac...@gmail.com wrote:
 FWIW, here's how I do something similar now, to avoid having many
 copies of the Qt libraries.

cool! Thanks for the description

 There is one master app, and several sub-apps.

 * call setup() for each of the apps, generating full separate apps
 with copies of the Qt libraries and other stuff
 -- each call has a unique directory sent in the setup options
 bdist_base and dist_dir. This avoids sharing build state, as
 mentioned earlier in the thread. This seems to work fine, calling
 setup() multiple times in the same script.

good to know -- I think the OP was right, the conflict over the
sharing build dirs -- I didn't know you could override that.

 * inside main app Contents/Resources, create empty sub.app/ directory
 * for each sub app:
 ** copy sub.app/Contents/MacOS into
 main.app/Contents/Resources/sub.app/Contents/MacOS
 ** copy sub.app/Contents/Info.plist into
 main.app/Contents/Resources/sub.app/Contents/Info.plist
 ** copy everything in sub.app/Contents/Resources/ that isn't include
 or lib into main.app/Contents/Resources/sub.app/Contents/Resources/
 ** create symlinks for sub.app/Contents/Resources/include -
 main.app/Contents/Resources/include (do the same with Resources/lib)

OK -- here is where Im confused -- with a sylink, you can do either
relative or absoute path, yes? absolute wouldn't work, as who knows
where the user will install it -- but relative could, as long as the
users keeps them all together -- is that how you handle it?

Alternatively I suppose you could require that main.app be installed
in /Library/Frameworks or something, and then symlink to the absolute
path.

I actually kind of like that idea, 'cause it would keep the apps a bit
more distinct, -- I have a base I want to use with multiple apps but
don't necessarily want folks to have to install everything at once to
use one.

 3. merge the contents of
 sub.app/Contents/Resources/lib/python*/site-packages.zip into the main
 app's copy using zipfile
 4. merge the contents of the
 sub.app/Contents/Resources/lib/python*/lib-dynload directory into the
 main app's directory


But anyway, this is a nice model for what py2app could so for us.

Thanks,
  -Chris

 NOTE: this will ignore any packages in
 sub.app/Contents/Resources/lib/python*/ that aren't in the
 site-packages.zip.
 That's fine for me, since I have the same packages option for all of the 
 apps.

 -mike


 On Thu, Sep 13, 2012 at 1:53 AM, Ronald Oussoren ronaldousso...@mac.com 
 wrote:

 On 13 Sep, 2012, at 10:47, Paul Wiseman poal...@gmail.com wrote:

 On 13 September 2012 07:18, Ronald Oussoren ronaldousso...@mac.com wrote:


 On 10 Sep, 2012, at 16:37, Paul Wiseman poal...@gmail.com wrote:

 Ah,

 I've found out how to recreate the error

 If I create a main.py with nothing but 'import sqlalchemy'

 then use the following setup.py:

 from setuptools import setup

 setup(
 version=1,
 name=TestApp1,
 app=[main.py],
 setup_requires=[py2app]
 )

 setup(
 version=1,
 name=TestApp2,
 app=[main.py],
 setup_requires=[py2app]
 )

 If it doesn't produce the error it's probably because of this: The
 cprocessors module in SQLAlchemy is written in C and compiles
 conditionally, based on if the current platform supports compiling it.   If
 not present, SQLAlchemy continues to work perfectly well as the hooks which
 attempt to import it will fall back to pure-Python functions instead. So
 you may have a cprocessors.py which I dont think you'd get the problem, only
 if it compiled the .so when sqlalchemy installed.


 I had the cprocessors extension in my build (that is, py2app mentioned in
 copied the extension)


 I get the error, but only when it builds the second app. In my main build
 script I make a few apps in the same script (I make 3 apps which get moved
 into the main app, any additional code in their site-packages.zip is moved
 into the main apps zip, I remove the sub-apps Contents/Resources/lib
 folder and symlink it at run time to the main apps lib folder.)

 Is this a bug or are you never supposed to run multiple setups in the same
 build? If not how can I achieve the above?


 Calling distutils.setup multiple times is at best untested with py2app,
 and I wouldn't be surprised if it causes problems due to state leaking from
 one build into the next.  A workaround would be to use the subprocess module
 to run the setup jobs in separate processes.


 Isn't the problem that they share dist folders, not a process? if not where
 does the state exist? Would I need to subprocess them from different
 directories?


 The py2app command itself has state and I haven't reviewed the code to know
 for sure that all state is cleaned up when the command is used twice in the
 same process. BTW. I also don't know if distutils.setup creates a new py2app
 command object every time it is called, if the second call to
 distutils.setup creates a new py2app command 

Re: [Pythonmac-SIG] Py2app error

[Chris Barker]

On Thu, Aug 2, 2012 at 8:32 PM, Ned Deily n...@acm.org wrote:

 These are what they seem to be -- though I think you got tripped up by
 for Mac OS X 10.3 through 10.6  -- actually, that should be 10.3 +
  -- 10.7 didn't exist when that was built.

 Actually, 10.3 through 10.6 is intentional.  If you need to build
 extension modules, the current 3.2.3 and 2.7.3 32-bit python.org Pythons
 do not work well with Xcode 4, the default for OS X 10.7 and 10.8 and
 optional for 10.6.

Indeed -- I had to go find and install XCode3.* -- Apple really wants
you to keep moving forward! But once I got XCode 3 going -- it works
fine.

Good to know that the INtel 32/64 bit python works with newer Xcodes though.

But if you're not building anything it will run fine on newer OS-X
systems, and if you want to be able to deploy on older systems, I
think you need to use it, yes?


  The upcoming Python 3.3 release has much better
 support for Xcode 4

Maybe I'll get there some day -- but it'll be 2.7 for a while yet.

 BTW, for Python 3.3, the 32-bit-only installer Python supports 10.5+
 systems (i386 and ppc).   More details on all of this forthcoming.

cool -- thanks for keeping this all up!

-Chris



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Py2app error

[Chris Barker]

On Wed, Aug 1, 2012 at 10:39 PM, Mark Livingstone
livingstonem...@gmail.com wrote:

 OK, taking Chris' advice, I installed on a Snow Leopard machine:

now that you've named, me, I feel compelled to contiue to help.. ;-)

 cheyenne:dist marklivingstone$ ls ~/Downloads/
 About Downloads.lpdf
 numpy-1.6.2-py2.7-python.org-macosx10.3.dmg
 wxMac-2.8.12.tar
 matplotlib-1.1.0-py2.7-python.org-macosx10.3.dmg
 python-2.7.3-macosx10.6.dmg

Careful here: Thanks to Apple's fast-moving development ( 4!
architectures potentially in the wild -- PPC32+64bit, Intel 32+64 bit)
it's hard to have something for eveyting...

note that you have

numpy-1.6.2-py2.7-python.org-macosx10.3.dmg
but
python-2.7.3-macosx10.6.dmg

we put the really long name in the numpy installer to try to make this
clear, but it really gets complicated fast...

Anyway, on the pyton,org site, there are:

Python 3.2.3 Mac OS X 64-bit/32-bit x86-64/i386 Installer (for Mac OS
X 10.6 and 10.7)

and

Python 3.2.3 Mac OS X 32-bit i386/PPC Installer (for Mac OS X 10.3 through 10.6)

These are what they seem to be -- though I think you got tripped up by
for Mac OS X 10.3 through 10.6  -- actually, that should be 10.3 +
 -- 10.7 didn't exist when that was built.

The numpy and wx packages you have are built for the 10.3 installer.

The release version of wx doesn't support 64 bit Intel (though it does
support 32 bit intel).


 wxPython2.8-osx-docs-demos-2.8.12.1-universal-py2.7.dmg
 mercurial-2.2.3_20120707-py2.7-macosx10.7

this looks like it may be for the newer installer.

 scipy-0.11.0rc1-py2.7-python.org-macosx10.6.dmg

this also -- so your scipy and numpy are out of sync, too!

 wxPython2.8-osx-unicode-2.8.12.1-universal-py2.7.dmg

this is for the 10.3 32 bit binary.

What a mess!

You have two options:

1) Use the 10.6 python binary (intel 32+64 bit), then get all the
packages compatible with that. IN this case, the trick will be wx. You
can:

  a) Make sure you run the binary in 32 bit mode (Not 64), and it
should work, but it's a bit messy to make sure that all works right.

  b) Use a new development build of wx (wx2.9.*) -- there is a 64 bit
Cocoa build available - but it does a few changes, so will take a bit
of work to port to.


2) (probably the easiest) -- use the 32bit 10.3+ build of Python --
then make sure all your other packages are built for that -- hopefully
you can find a Mercurial package for it -- the rest are there. (it may
not be hard to build mercurial, either, does it have any
dependencies?)

Sorry for the mess -- blame Apple!

 I tried a build but got this:

  python ../mac-setup/setup_py2app.py py2app
 Traceback (most recent call last):
   File ../mac-setup/setup_py2app.py, line 1, in module
 import wx
   File 
 /usr/local/lib/wxPython-unicode-2.8.12.1/lib/python2.7/site-packages/wx-2.8-mac-unicode/wx/__init__.py,
 line 45, in module
 from wx._core import *
   File 
 /usr/local/lib/wxPython-unicode-2.8.12.1/lib/python2.7/site-packages/wx-2.8-mac-unicode/wx/_core.py,
 line 4, in module
 import _core_
 ImportError: 
 dlopen(/usr/local/lib/wxPython-unicode-2.8.12.1/lib/python2.7/site-packages/wx-2.8-mac-unicode/wx/_core_.so,
 2): no suitable image found.  Did find:
 
 /usr/local/lib/wxPython-unicode-2.8.12.1/lib/python2.7/site-packages/wx-2.8-mac-unicode/wx/_core_.so:
 no matching architecture in universal wrapper

Well -- no ;point in going beyond this -- wx isn't working. What
you've got is a a 32 bit PPC+Intel wx, but you're running a 32+64 bit
Python -- and it defaults to 64 bit on a 64 bit machine -- so it's
looking for a 64bit Intel binary of wx -- which is not there.

 However, when I try to run the app, I get the following in the console log:
 ImportError: 
 dlopen(/Users/marklivingstone/Documents/workspace/salstat-statistics-package-2/src/dist/SalStat.app/Contents/Resources/lib/python2.7/lib-dynload/wx/_core_.so,
 2): no suitable image found.  Did find:

same error -- no surprise there -- if it doesn' work outside of
py2app, it won't work with it.

 Is it just not possible to use py2app to create an app for the Mac based on 
 wx?

indeed it is -- I'm doing it with most of the same stuff you are
(except Mercurial) (using the 32 bit build)


NOTE: I'm considering building a custom 32bit Intel (10.4+, maybe)
only distribution for the Mac -- it would run on any recent system,
and be smaller to bundle, etc.

Or maybe 64 bit -- how common are 32 bit only Intel Mac these days --
anyone know?

 Also, the final result turns in at 184MB in size. Are there any common
 things that may be being pulled in that I should exclude?

Well, that's a trick. It's going to be big -- you've got multiple
binaries in there for different architectures -- so all the binary
stuff is doubled. Then you've got packages that bring the world in
with them:

wx is big -- not much to be done about that though you may be able to
pull out an so or two.)

numpy default imports a bunch of stuff like ffts, lapack, etc that you
may or may not be 

Re: [Pythonmac-SIG] py2app: works for me on 10.6, not 10.7

[Chris Barker]

On Tue, Jul 31, 2012 at 7:47 AM, Michael McCracken
michael.mccrac...@gmail.com wrote:
 Hi, my py2app setup script is working fine if I run it on 10.6, but on
 10.7 I've run into some problems.

 I want a standalone app, and on 10.6 I didn't specify semi_standalone:
 False in the options, and it worked fine.
 On 10.7, it appeared to be using the system python (loading old system
 versions of some dependencies),

I'm not totally sure, but 10.7 probably has a version of python out of
the box that 10.6 doesn't. But anyway, if you want it standalone, you
need to make sure that you DONT'T use Apple's Python:

Did you install the same python.org versions on 10.7 as you did on 10.6?

Are you sure you're running py2app (i.e. setup.py py2app) with that Python?

If so, py2app should keep it all clear for you.

(note: if any extensions need to be compiled, you need to make sure
you use an older XCode, also, but if your app is running fine with the
right pyton outside py2app, then you should be set.)

HTH,
 -Chris


 and on a quick look through the py2app
 code it seemed to be deciding it was semi-standalone, so I added
 semi_standalone: False.
 This solved results in a app wrapper without the Python.framework
 copied in, giving me the Python runtime could not be located error.

 Is there something obvious I'm missing in moving builds to 10.7?

 Thanks,
 -mike
 ___
 Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
 http://mail.python.org/mailman/listinfo/pythonmac-sig
 unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Question about py2app packages and includes options

[Chris Barker]

On Tue, Jul 17, 2012 at 3:49 PM, Michael McCracken
michael.mccrac...@gmail.com wrote:

 That makes sense - but as you mention, it seems like there's some
 missing functionality.

I think so, yes, but it can get the job done.

 However, it's no fun if you have a lot of subpackages to add that way.

nope -- but for the most part they are picked up by regular imports,
anyway. You only need to do this if there are some dynamic importing
in your code -- and in that case, it's likely you'll want the whole
package anyway.

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Question about py2app packages and includes options

[Chris Barker]

On Tue, Jul 17, 2012 at 11:03 AM, Michael McCracken

 My question is: why does 'packages' copy the package recursively, but
 not into the .zip,

because there are packages that don't work right if zipped -- so this
gets around that.

 while 'includes' only gets single modules?

I suspect it's because there should be a way to include a particular
module without the whole package. Essentially:

includes adds a module to list, just as thought there were an
import module name line in the code -- it is used to cover dynamic
imports that won't be caught by walking the code.

packages makes na compete copy of the package, and puts it outside
the zip bundle -- this is fro including packages that have auxiliary
files, etc, and/or can't be zipped for other reasons.

It's a big ugly, but I've managed to put packages into the zip with
something like this:

includes = [package,
package.subpackage
package.subpackage.module1
package.subpackage.module2
]

for some reason (is it a bug? -- or has it been fixed?) doing:

includes = [ package.subpackage.module]

puts module in the root, so it's there but can't be imported the same way.

HTH,

- Chris



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Py2app error

[Chris Barker]

On Mon, Jul 16, 2012 at 10:49 PM, Ronald Oussoren ronaldousso...@mac.com wrote

 I guess I'll have to download EPD to test this, but it looks like EPD has a 
 Python.framework where the framework version is different from the Python 
 version, and parts of py2app assume they are the same (which it why copying 
 pyconfig.h succeeds but copying Makefile fails).

Also -- check the license on the version(s) of EPD you are using --
you may not be free to re-distribute in this way anyway -- at least
that used to be the case.

-Chris



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Problem Running App built with Py2App

[Chris Barker]

it's best to keep this on the list (not the default reply option...)

 What console app are you referring to?

/Applications/Utilities/Console.app


 When we built with 2.6, we were on
 OSX 10.5, but since we're getting the same error of both OSX 10.5 and 10.7
 with Py 2.7 it seems that OS version is not the issue.

are you building and running on the same OS version (at this point...)

 We are using the
 python.org distribution.

 I've thought it could be caused by a missing dependency, but regardless of
 what options we pass to py2app running the app results in the same error.

yup -- weird, if Console.app doesn't give you any more hints, you'll
need to start from a small minimal app and work your way up...

-Chris



 Mike


 On 7/9/2012 10:40 AM, Chris Barker wrote:

 On Sat, Jul 7, 2012 at 5:38 PM, Michael Forzano
 michaeldforz...@gmail.com  wrote:

 I'm trying to build an app with Py2app. I'm on Python2.7 and Mac OSX
 10.7.
 The error occurs on OSX 10.5 as well. The app builds successfully, but
 when
 running it in console with the command:
 rsg.app/Content/MacOS/rsg
 I get the following error:
 2012-07-05 20:34:56.090 rsg[7483:707] rsg Error
 Does anyone know what's going on or how we might be able to get some more
 information, i.e. a stack trace?

 the Console app often report a more useful message when a py2app app
 crashes.

 The app uses WXPython among other things.
 The app ran fine when built on 2.6, but due to our updated code depending
 on
 2.7 this is no longer an option.

 Were you building on OS-X 10.7 in both cases?

 Are you using the python.org build of python 2.7?

 Anyway, I'd make sure you have the latest py2app and its dependencies
 in the pyton you are using, and then do as suggested, start really
 simpel and slowly add more.

 py2app works fine for me with python2.7 and wxPython on OS-X 10.6 -- I
 haven't treid 10.7 yet.

 HTH,
   -Chris

   If you guys need more info let me know, as

 this error isn't very descriptive so not sure where to even start looking
 for the cause.

 Thanks,
 Mike
 ___
 Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
 http://mail.python.org/mailman/listinfo/pythonmac-sig
 unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG







-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] py2app bug with argv_emulation=True

[Chris Barker]

On Fri, May 25, 2012 at 5:34 PM, Michael O'Donnell mi...@wagsoft.com wrote:
 He found that if you set argv_emulation to False, the program
 worked as expected.

 NOW, I need argv_emulation, since a user might open my application by
 double clicking on a document associated with my program.  I don't want to
 lose
 this functionality (which users are used to by now) just because of a bug.

Perhaps argv emulation isn't the only way to support this. Does
tkInter on the Mac Support the Mac-specific events? For example,
wxPython has mac-specific events you can catch for files dropped on
the app, or selected at startup -- so argv emulation isn't required.
Maybe Tk doesn't have those, but it's worth a look.


 Now, I find it atrange that a bit of code which deals with passing
 command line args to the program should mess up Tkinter's
 windowing, just doesn't make sense.

I agree -- though I suppose it could be interfering with the TK code
to handle it -- so maybe it does exist.

good luck,
  -Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Help with Py2app

[Chris Barker]

On Mon, Apr 30, 2012 at 4:26 AM, Charlie Clark

 I'm trying to update the setup script for the LinkChecker project
 http://linkchecker.sourceforge.net/ because it no longer builds the app and
 does not work reliably in a virtualenv.

darn...

 I am hoping to build a standalone
 app and package it as a DMG as the project author no longer
 has access to Apple hardware.

thanks for contributing in this way!

 although `bin/python setup.py py2app` should in theory be
 sufficient.

it should, yes, though at times I've had to add explicte
most-processing code -- I usually do it in pyton in teh setup.py, but
in some ways makefile might be easier if you're more familiar with
shell scripting. I also use a shell script to build the dmg.


 tried to break out the py2app part into a separate script.

 and followed the py2app documentation it became clear that the script needs
 to be updated to use setuptools, at least for the extensions.

I don't know that py2app reslies on setuptools for anything.

 LinkChecker is a QT project and needs Python-SIP. Unfortunately I haven't
 worked out how the recipe works. Does the py2app automatically detect the
 dependency and build and package the shared libraries automatically?

it shoujld, yes -- the idea of recipies is that they jsut work for
the end user. If it's not, then it's a bug -- hopefully someone here
can help you find and fix it.

please post:

your setup.py

the errors you get when running the .app

Also, what I usually do is look inside the generated bundle and see
what's there -- if you find what's missing, you can often figure out
how to fix it.

you can unzip the site-packages zip file, to see what's in there.

HTH,
 -Chris


 Thanks for any help.

 Charlie
 --
 Charlie Clark
 Managing Director
 Clark Consulting  Research
 German Office
 Kronenstr. 27a
 Düsseldorf
 D- 40217
 Tel: +49-211-600-3657
 Mobile: +49-178-782-6226
 ___
 Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
 http://mail.python.org/mailman/listinfo/pythonmac-sig
 unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Help with Py2app

[Chris Barker]

On Mon, Apr 30, 2012 at 10:20 AM, Charlie Clark

 tried to break out the py2app part into a separate script.

I'd go farther with this...

 I don't know that py2app reslies on setuptools for anything.

 Maybe it doesn't but I got an error when I moved the relevant part of
 setup.py over to a new file generated by py2applet. It was complaining about
 the Extensions not being Extension instances.

right...

 dependency and build and package the shared libraries automatically?

note here -- it should include them, but having it both build and
package in one step may not work...

 please post:
 your setup.py

 And my feeble attempt:

 http://pastebin.com/ASzHipCe

OK -- to keep this all cleaner, I'd completely separate building and
py2app-ing. So the steps would be:

python setup.py install (or install, or develop)

make sure it's all running in that environment. Then:

python setup.py py2app

having py2app use the distutils API was a nifty idea, but I'm not sure
it's bought us anythign bu confusion in practice. The the setup.py
would either be completely separate, or you can have a clause in
there:

if py2app in sys.argv: (or somethign like that)
# do the py2app stuff here


they key is not to try to use the same call to distutils.setup to
build, install, and py2app.

I usually end up with essentially completely different setup.py for
installing, py2exe and py2app, though they may be in the same file or
not.

HTH,
   -Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Help with Py2app

[Chris Barker]

(dont' forget to include pythonmac-sig -- it's not doen with a standard reply.)

On Mon, Apr 30, 2012 at 2:07 PM, Charlie Clark
charlie.cl...@clark-consulting.eu wrote:

 That's a setuptools (or distribute) feature, and should be in the
 primary setup.py that the main developer uses on other platforms.

 Well, where should it go in the existing setup.py? I just tried it in the
 args but no joy.

it goes in requires somwhere -- check the setuptools docs.

 python setup.py py2app
 yup -- a dmg is easy, a one liner, something like:
 /usr/bin/hdiutil create -srcfolder dist -volname Name_of_the_volume
 -ov The_name_of_the_file
 there is bdist.mpkg, but I think that's only for python packages, not
 app bundles.


 Can I add that to my build script?

you can use an os.system callina python script, but I usually jsut run
it separately.



 I'm now getting the same error as when running the original setup.py

    raise TypeError(Don't know how to handle '%s' % repr(src))
 TypeError: Don't know how to handle
 ''/Users/charlieclark/Sites/LinkChecker/linkchecker-gui''

what is link-checker-gui ?

from that error, it looks like neither a module (clearly not - it's
not called *.py) or a package (would be a directory).

Also, it's in your home dir -- so why is it getting found by modulegraph?


 At least I've got it pointing at the right script. So it can't resolve the
 dependencies?

that looks like something else than not finding a dependency.

-Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] py2app and nested packages

[Chris Barker]

On Tue, Apr 24, 2012 at 4:29 AM, Ronald Oussoren

 example: the pubsub package is delivered with wxPython, so it is
 commonly imported thusly:

 from wx.lib.pubsub import Publisher

 wx.lib.pubsub is a bad example, it manipulates __path__ which causes problems 
 with py2app because it cannot detect this.  I added a recipe to py2app's 
 repository a while ago that should fix this particular problem.


I thought I had the latest -- I'll go check that out.

Also, there is a bit of trick if you force it to import it's dyanamic
module, but if you've solved that one, great!


 That's a bug, the code that implements the packages options assumes that all 
 mentioned packages are toplevel packages.  It should be fairly easy to fix 
 that, although this requires some path manipulation trickery because the 
 subpackage will be in a different location that the parent: the parent is in 
 site-packages.zip while the child is not.

right -- do you have an idea how to solve that? I don't!

 The option packages currently always stores the included package outside of 
 site-packages.zip to ensure that data files can be loaded in the old 
 pre-pkgresources way (that is, by opening paths relative to 
 somepackage.__file__).

which is useful, but another thought -- maybe there could be two options:

packages and full_packages or something -- so one would simple add
the package to the modulegraph, to catch dynamic imports, and the
other would do what is done now -- include the whole darn thing.

One other issue with the whole darn thing option, is that you get
the *.py, *.pyc, Na *.pyo files -- so it's maybe three times as big as
it could be -- I wonder if it's worth cleaning that up.

 Is there a way to turn off a recipe (other than deleting it from the 
 install)?

 No, and I'd prefer to fix recipes instead of having a way to disable them.

I understand that, and generally agree -- but it may be that there is
no one recipe that works for everyone. For example, Scipy is weird
enough that probably the only way to be sure it'll work in all cases
is to include the whole darn thing -- but in my case at least, I'm
using a couple functions in scipy.special, and it works fine if that
is all I include.

Maybe if there is a way to pass options to recipes?

 The (scipy) recipe should get a way to specify which dynamic imports are 
 present, simular to the hardcoded knowledge about the stdlib in modulegraph. 
 That way py2app can include only the bits that are really necessary.

If you give me a pointer - maybe to the similar modulegraph code,
perhaps I could work on that.

 IIRC the matplotlib recipe includes the entire package because of the data 
 files that are in the package, including only the code doesn't work.

I've poked into this more -- it turn out that there is special-case
code in matplotlib itself for py2exe that looks for the data-files in
a different place when sys.frozen -- I'm adding some code for py2app
as well -- if I get that working, I can submit a patch to MPL and the
recipe.

Is there a way to specify data files in a recipe?

- Is there a way to apply excludes after the recipe? As far as I can
 tell, if the recipe includes it, excludes doesn't remove it.

 That's correct, and is a bug: user specified actions should override  
 automatic actions, including the recipes.

OK -- I suspect the issue is there is no way to exclude stuff that is
going to go outside of the zip file -- the full packages. It looks
like what it does is remove it from modulegraph only.

Thanks for your work (and ideas) on this.

-Chris




-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] py2app and nested packages

[Chris Barker]

Folks,

py2app doesn't seem to do the right thing with nested packages.
However, it's not entirely clear what it should do...

example: the pubsub package is delivered with wxPython, so it is
commonly imported thusly:

from wx.lib.pubsub import Publisher

However, in wx.lib.pubsub, there is some trickery in the __init___, so
as py2app installs it, ot doesn't work (see previous messages to this
and the wxPython list). However, if you do:

packages = ['wx.lib.pubsub']  ...

in your py2app setup.py, you get the entire pubsub package, but installed in :

Peppy.app/Contents/Resources/lib/python2.7/pubsub

so it will work, but only if you now import it as:

from pubsub import Publisher

not too heinous, but it's really nice if we don't have to change
imports for the bundled version.

if I add 'wx' to packages, It does work, but I've then got all of wx,
all of wx.lib, etc, which is  really a bit much (the resulting app
bundle is 124MB, vs. 60 without specifying the wx package)

At first, I thought I'd want:

wx/lib/pubsub/

put on sys.path, with wx and lib empty except the specified dirs.
However, that would put two wx dirs on sys.path, which would not be
good (assuming wx is used...)

Would it be possible for the packages specification to be processed
after modulegraph is run, and it would then see that wx and wx.lib
are there, and then put all of pubsub in there? Or maybe put the parts
of wx and wx.lib that were already going to be included outside the
zip bundle?

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] py2app and nested packages

[Chris Barker]

Another couple py2app questions:

Ive discovered that my app is HUGE! -- I already expected that, but
this is a bit out of bounds. The reason:

The scipy and matplotlib packages bring in all of scipy, numpy, and
matplotlib uncompressed. This gets pretty darn big, particularly when
you're using one or two simple functions from scipy, for instance.

I know why they do that -- there are a number of dynamic inports, and
folks often include matplotlib and/or scipy in apps where people may
be scripting, etc, and using features that aren't always imported by
the app. And this way, apps using those libs just work which is
great.

However, it would be nice to be able to override soem of this:

Is there a way to turn off a recipe (other than deleting it from the install)?

- Is there a way to apply excludes after the recipe? As far as I can
tell, if the recipe includes it, excludes doesn't remove it.


-Chris



On Mon, Apr 23, 2012 at 11:42 AM, Chris Barker chris.bar...@noaa.gov wrote:
 Folks,

 py2app doesn't seem to do the right thing with nested packages.
 However, it's not entirely clear what it should do...

 example: the pubsub package is delivered with wxPython, so it is
 commonly imported thusly:

 from wx.lib.pubsub import Publisher

 However, in wx.lib.pubsub, there is some trickery in the __init___, so
 as py2app installs it, ot doesn't work (see previous messages to this
 and the wxPython list). However, if you do:

 packages = ['wx.lib.pubsub']  ...

 in your py2app setup.py, you get the entire pubsub package, but installed in :

 Peppy.app/Contents/Resources/lib/python2.7/pubsub

 so it will work, but only if you now import it as:

 from pubsub import Publisher

 not too heinous, but it's really nice if we don't have to change
 imports for the bundled version.

 if I add 'wx' to packages, It does work, but I've then got all of wx,
 all of wx.lib, etc, which is  really a bit much (the resulting app
 bundle is 124MB, vs. 60 without specifying the wx package)

 At first, I thought I'd want:

 wx/lib/pubsub/

 put on sys.path, with wx and lib empty except the specified dirs.
 However, that would put two wx dirs on sys.path, which would not be
 good (assuming wx is used...)

 Would it be possible for the packages specification to be processed
 after modulegraph is run, and it would then see that wx and wx.lib
 are there, and then put all of pubsub in there? Or maybe put the parts
 of wx and wx.lib that were already going to be included outside the
 zip bundle?

 -Chris


 --

 Christopher Barker, Ph.D.
 Oceanographer

 Emergency Response Division
 NOAA/NOS/ORR            (206) 526-6959   voice
 7600 Sand Point Way NE   (206) 526-6329   fax
 Seattle, WA  98115       (206) 526-6317   main reception

 chris.bar...@noaa.gov



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] shrink app bundle size (removing unused stuff)?

[Chris Barker]

Nothing to do with your issue (I don't think) but:


On Tue, Mar 13, 2012 at 5:17 PM, Carlos Grohmann  *** using recipe:
virtualenv ***
 *** using recipe: sip ***
 *** using recipe: matplotlib ***
 *** using recipe: numpy ***
 *** using recipe: wx ***

recipe sip is usually used for PyQT (as sip is used to build pyQT) It
seems odd that you'd have both SIP and wx in one app.

Or is sip used fro something else that you're using?

-Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] shrink app bundle size (removing unused stuff)?

[Chris Barker]

On Wed, Mar 14, 2012 at 2:24 PM, Carlos Grohmann
carlos.grohm...@gmail.com wrote:
 I don't use sip at all. don't know why it's been used by py2app.

one guess -- there is an optional QT back-end to matplotlib -- is
py2app picking that up (It may drag in TK and even GTK, too). MIght be
worth taking a look.

-Chris





 Carlos

 On Wed, Mar 14, 2012 at 17:46, Chris Barker chris.bar...@noaa.gov wrote:

 Nothing to do with your issue (I don't think) but:


 On Tue, Mar 13, 2012 at 5:17 PM, Carlos Grohmann  *** using recipe:
 virtualenv ***
  *** using recipe: sip ***
  *** using recipe: matplotlib ***
  *** using recipe: numpy ***
  *** using recipe: wx ***

 recipe sip is usually used for PyQT (as sip is used to build pyQT) It
 seems odd that you'd have both SIP and wx in one app.

 Or is sip used fro something else that you're using?

 -Chris

 --

 Christopher Barker, Ph.D.
 Oceanographer

 Emergency Response Division
 NOAA/NOS/ORR            (206) 526-6959   voice
 7600 Sand Point Way NE   (206) 526-6329   fax
 Seattle, WA  98115       (206) 526-6317   main reception

 chris.bar...@noaa.gov
 ___
 Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
 http://mail.python.org/mailman/listinfo/pythonmac-sig
 unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG




 --
 Prof. Carlos Henrique Grohmann - Geologist D.Sc.
 Institute of Geosciences - Univ. of São Paulo, Brazil
 ---
 http://www.igc.usp.br/pessoais/guano
 http://www.igc.usp.br/openstereo
 http://lattes.cnpq.br/5846052449613692 (CV)
 ---
 Twitter: @CarlosGrohmann
 http://carlosgrohmann.tumblr.com/
 
 Can’t stop the signal.



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] PyCon..

[Chris Barker]

A note about sprint topics:

One of the things we might want to work on is docs.

There is also a sprint on:

Python-Guide.org

The Mac-OS-X page essentially tels folks that they should install
homebrew, and then build eveything from there (plus Distribute and
virtualenv). I'm not convinced that that's the best option for all
users (though probably a good one for ex-*nix folks)

Anyway, we might want to work on that page some...

-Chris




On Sun, Mar 11, 2012 at 8:48 AM, Ronald Oussoren ronaldousso...@mac.com wrote:

 On 10 Mar, 2012, at 22:57, Ned Deily wrote:

 In article 20120311020302.ga31...@illinois.edu,
 Nicholas Riley njri...@illinois.edu wrote:
 On Sat, Mar 10, 2012 at 04:56:26PM -0800, Ronald Oussoren wrote:
 On 10 Mar, 2012, at 15:05, Chris Barker wrote:
 On Tue, Feb 14, 2012 at 7:23 AM, Ned Deily n...@acm.org wrote:
 I'm planning to sprint through Thursday.   I've added a  Mac OS X
 Support
 project to the PyCon sprint page.  Feel free to add topics and add
 yourself.  Hope to see you all there!
 I'm at PyCon (with a laptop/external drive that has 10.6, 10.7 and
 10.8 installed, so I can do some testing across OSes) and should be
 able to spend a day or two sprinting on MacPython.

 Great!

 Thanks, Ronald, for the summary.   The highest-priority items I think
 are to get Python 3.3 ready for release

 One thing to look into w.r.t. is to look at the new functions in the os/posix 
 module (and possibly other extension modules as well)

 1) Do or could these work on OSX

 2) How does the affect the installer, in particular w.r.t. symbols available 
 on the build machine but not on earlier OSX releases. Posixmodule.c already 
 contains some code to deal with this for a number of functions.

 Issue 1404  http://bugs.python.org/issue14104 is about adding a monotonic 
 timer to the OSX port, with the same interface as is used for the linux port.

 Ronald


 ___
 Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
 http://mail.python.org/mailman/listinfo/pythonmac-sig
 unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG




-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] shrink app bundle size (removing unused stuff)?

[Chris Barker]

On Fri, Mar 9, 2012 at 7:22 AM, Ronald Oussoren
 Py2app will never be able to do everything, but I'd prefer to get closer than 
 we're currently.

A laudable goal, for sure -- and we much appreciate your work on py2app.

 Are there things you have to do every time that could
 (easily) be expressed as configuration for py2app?

As suggested, 'include', 'excludes', and 'packages' could perhaps be
more robust.

I haven't checked recently -- have you fixed the issue where you had
to explicitly include the parent package when you want to includ ea
sub-package?

ie. you want to be able to :

import libA.libB

(but nothing else in libA)

IN the past, I've had to do:

packages = ['libA', 'libA.libB']

ANother major thought:

I've thought that maybe we need a way to build a module graph from
run-time information, rather than code inspection -- that would
address both:

importing packages you don't need
and
fancy dynamic imports.

The trick is that you'd need to have a way to run your code that
guaranteed that eveything ws imported that might be needed (i.e.
dynamci import), but it seems that you'd want test code that did that
anyway.

I may be missing something, but it seems all you'd need to do is look
at sys.modules, and write out a modulegraph (or would it even need to
be  graph? a simple list would do...)

Then Py2app would need a way to load the modulegraph (or list) from a file.

Even without a runtime inspector -- this could be handy as you could:

1) only re-run the code inspection part when you knew you'd added a
module, rather than on every build

2) you could tweak the module graph by hand and re-use it, rather than
tweaking the resulting package.

Anyway, maybe too much architectural work for now...

 1) I added a py2app recipe that does the right thing
 with the pubsub library in wxPython. That library uses
 __path__ hacks and that confuses modulegraph (and
 hence py2app). Because of this you no longer have to
 explicitly include 'wx' in the application bundle

Very nice! I happen to need that for a project right now.

 2) I tweaked the matplotlib recipe in py2app, it no
 longer copies the entire package but adds a hook to
 tell matplotlib where its data is. This solution is not fully
 complete yet, I'm currently including mpl-data twice
 (once in Resources, once in site-packages.zip) and
 the later copy is not needed.

also nice -- did you use:

matplotlib.get_py2exe_datafiles()

That is handy for py2exe.

Thanks for you work...

-Chris













  It seems that python is slowly moving towards a more declarative way
of specifying builds using a setup.cfg file instead of setup.py though
the distutils2/packaging project and py2app should do the same when
that happens (without dropping support for setup.py files of course).

 Ronald




-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] PyCon..

[Chris Barker]

On Tue, Feb 14, 2012 at 7:23 AM, Ned Deily n...@acm.org wrote:

 I'm planning to sprint through Thursday.   I've added a  Mac OS X Support
 project to the PyCon sprint page.  Feel free to add topics and add
 yourself.  Hope to see you all there!

Ive seen neither you nor Ronald yet...

I'm here(there) Monday -- not suer what I'm sprinting on yet -- any
ideas what you'd like to do for MacPython?

I do note that there are a LOT of macs here -- but darn few MacPython
folks -- I suppose most of them use it like *nix, and don't need/want
anything mac-specific.

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] (re)newbie py2app question

[Chris Barker]

On Sun, Mar 4, 2012 at 7:28 PM, Charles Hartman co...@conncoll.edu wrote:
  My wxPython (classic, they call it,
 for no clear reason;

IN case you're curios -- classic refers to it being the latest
version of the SWIG-based wrappers that have been around for years --
Robin is now working on an updated wxPython built differently, that he
calls Project Phoenix.

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Fwd: distutils and stdarg.h

[Chris Barker]

On Thu, Feb 9, 2012 at 1:30 PM, Chris Barker chris.bar...@noaa.gov wrote:
  If it is using C++
 code, though, you may have to override that yourself since Python itself
 does not contain any C++ code and I don't think there is any special
 code in Distutils to override C++ stuff.

 That could be it, too.

 2) how do I use 4.01. with distutils?

 For the any C++ modules, you may need to override the C++ compiler
 choice by using a CXX environment variable.

 OK -- I'll try that.

Bingo! I did:

$ export CXX=/usr/bin/g++-4.0

then

$ python setup.py build

and it built fine.

Actually, it chocked when it couldn't find the wxPython libs, but I
disab'ed that, as I don't need it right now -- and then it built fine.

Thanks so much for your help!

-Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] Fwd: distutils and stdarg.h

[Chris Barker]

darn, forgot to send to the list again -- I hate these defaults!



-- Forwarded message --
From: Chris Barker chris.bar...@noaa.gov
Date: Thu, Feb 9, 2012 at 9:58 AM
Subject: Re: [Pythonmac-SIG] distutils and stdarg.h
To: Ronald Oussoren ronaldousso...@mac.com


On Wed, Feb 8, 2012 at 11:33 PM, Ronald Oussoren ronaldousso...@mac.com wrote:
 against the python.org 32 bit Intel/PPC build of python 2.7

 I'm getting a bunch of errors like:

 /Developer/SDKs/MacOSX10.4u.sdk/usr/include/stdarg.h:4:25: error:
 stdarg.h: No such file or directory

 That file does exist, but it uses:

 #include_next stdarg.h

 What compiler version do you use?

It's using g++ 4.2.1

 One thing you could try is to drop support for ppc, for example by adding 
 [-arch, i386] to extra_compiler_args in the definition of the Extension 
 in setup.py.

I'll give that try, but ...

  Recent Xcode releases do not include a compiler that supports the powerpc 
 architecture.

I've made a point of not upgrading XCode for that reason -- and I'm
not having trouble compiling PPC versions other extensions.

I'm pretty sure I've done both C and C++ ones, too.

I'm thinking that some of the standard stuff that distutils adds has
been overridden by this build -- it's a big, complicated setup, using
numpy, distutils, etc. I'm having trouble following it all (or
simplifying it -- I don't need the whole package anyway). Entought is
no longer testing on this distribution of Python, nor PPC at all, I
believe, so they could have inadvertently broken it easily enough.

thanks,
  -Chris



--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

chris.bar...@noaa.gov


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Fwd: distutils and stdarg.h

[Chris Barker]

On Thu, Feb 9, 2012 at 11:37 AM, Russell E. Owen ro...@uw.edu wrote:

 I suggest you try one of these things:
 - Use gcc 4.0.1 to build extensions for 32-bit python.org python. That's
 what I'm still doing. It requires XCode 3.x.

Thanks -- Ill try that. but:

1) I thought distutils took care of calling the right compliler to
match what pyotn had been built with. I guess not.

2) how do I use 4.01. with distutils?

Thanks,
   -Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Fwd: distutils and stdarg.h

[Chris Barker]

On Thu, Feb 9, 2012 at 12:55 PM, Ned Deily n...@acm.org wrote:
 1) I thought distutils took care of calling the right compliler to
 match what pyotn had been built with. I guess not.

 Distutils *does* try to call the right CC compiler (that is, the
 compiler the Python itself was built with), unless the
 module/package/distribution's setup.py overrides it.

it's possible that that's what's happening -- as I said, this is an
ugly complicated mess.

  If it is using C++
 code, though, you may have to override that yourself since Python itself
 does not contain any C++ code and I don't think there is any special
 code in Distutils to override C++ stuff.

That could be it, too.

 2) how do I use 4.01. with distutils?

 For the any C++ modules, you may need to override the C++ compiler
 choice by using a CXX environment variable.

OK -- I'll try that.

 What OS version are you trying this on, BTW?

10.6.8 Intel Corei7

I'll le tyou know how it works out when a get a chance.

Thanks for your ideas.

Any of you going to PyCon this year?

-Chris





-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] distutils and stdarg.h

[Chris Barker]

HI folks,

I'm trying to build the Enthought Tool Suite Enable package

(http://code.enthought.com/projects/index.php)

 against the python.org 32 bit Intel/PPC build of python 2.7

I'm getting a bunch of errors like:

/Developer/SDKs/MacOSX10.4u.sdk/usr/include/stdarg.h:4:25: error:
stdarg.h: No such file or directory

That file does exist, but it uses:

#include_next stdarg.h

So apparently there isn't a stdarg.h later on in the include path.

There are a LOT of versions of stdarg.h on my system, so it's less
than obvious which one should get picked up. Also, shouldn't distuitls
set the include dirs to get this anyway? Even if I find one that
works, I'd hate to hard-code that in there.

any thoughts?

-Chris



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] distutils and stdard C++ headers..

[Chris Barker]

putting this in the same thread, as maybe it's related:

if I get past the stdarg issues, I then get to:

compiling C++ sources
C compiler: c++ -fno-strict-aliasing -fno-common -dynamic -isysroot
/Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -g -O2 -DNDEBUG
-g -O3

compile options: '-D__DARWIN__ -Ikiva/agg/src
-Ikiva/agg/agg-24/include -Ikiva/agg/agg-24/font_freetype
-Ikiva/agg/freetype2/src/autofit -Ikiva/agg/freetype2/src/base
-Ikiva/agg/freetype2/src/bdf -Ikiva/agg/freetype2/src/cache
-Ikiva/agg/freetype2/src/cff -Ikiva/agg/freetype2/src/cid
-Ikiva/agg/freetype2/src/gxvalid -Ikiva/agg/freetype2/src/gzip
-Ikiva/agg/freetype2/src/lzw -Ikiva/agg/freetype2/src/otvalid
-Ikiva/agg/freetype2/src/pcf -Ikiva/agg/freetype2/src/pfr
-Ikiva/agg/freetype2/src/psaux -Ikiva/agg/freetype2/src/pshinter
-Ikiva/agg/freetype2/src/psnames -Ikiva/agg/freetype2/src/raster
-Ikiva/agg/freetype2/src/sfnt -Ikiva/agg/freetype2/src/smooth
-Ikiva/agg/freetype2/src/tools -Ikiva/agg/freetype2/src/truetype
-Ikiva/agg/freetype2/src/type1 -Ikiva/agg/freetype2/src/type42
-Ikiva/agg/freetype2/src/winfonts -Ikiva/agg/freetype2/src/gzip
-Ikiva/agg/freetype2/include -Ikiva/agg/freetype2/src
-I/Developer/Headers/FlatCarbon
-I/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Kernel.framework/Versions/A/Headers/
-I/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include
-c'
c++: kiva/agg/src/kiva_hit_test.cpp
c++: kiva/agg/src/kiva_graphics_context_base.cpp
In file included from kiva/agg/src/kiva_graphics_context_base.cpp:14:
kiva/agg/src/kiva_graphics_context_base.h:13:17: error: stack: No such
file or directory
kiva/agg/src/kiva_graphics_context_base.h:14:18: error: vector: No
such file or directory

vector, and stack are presumably C++ standard library stuff. shold
g++ have those on it's path already?

-isysroot /Developer/SDKs/MacOSX10.4u.sdk

is there -- shouldn't it take care of itself from there?

This is making me think that this distutils script (a complicated
one...) is somehow overriding some standard stuff.

any ideas??

-Chris


On Wed, Feb 8, 2012 at 12:14 PM, Chris Barker chris.bar...@noaa.gov wrote:
 HI folks,

 I'm trying to build the Enthought Tool Suite Enable package

 (http://code.enthought.com/projects/index.php)

  against the python.org 32 bit Intel/PPC build of python 2.7

 I'm getting a bunch of errors like:

 /Developer/SDKs/MacOSX10.4u.sdk/usr/include/stdarg.h:4:25: error:
 stdarg.h: No such file or directory

 That file does exist, but it uses:

 #include_next stdarg.h

 So apparently there isn't a stdarg.h later on in the include path.

 There are a LOT of versions of stdarg.h on my system, so it's less
 than obvious which one should get picked up. Also, shouldn't distuitls
 set the include dirs to get this anyway? Even if I find one that
 works, I'd hate to hard-code that in there.

 any thoughts?

 -Chris



 --

 Christopher Barker, Ph.D.
 Oceanographer

 Emergency Response Division
 NOAA/NOS/ORR            (206) 526-6959   voice
 7600 Sand Point Way NE   (206) 526-6329   fax
 Seattle, WA  98115       (206) 526-6317   main reception

 chris.bar...@noaa.gov



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] [py2app] packaging an egg using pkg_resources

[Chris Barker]

On 10/20/2011 2:35 AM, Ronald Oussoren wrote:

  * py2app is not designed to use eggs


That's corrrect. Py2app currently does not copy egg metadata into the
application bundle.


  * pkg_resources requires a distribution format like eggs to have the
required metadata to introspect a package.


That's correct as well.



Does this assumptions are true?  Does that means I have to purge code
from pkg_resources calls?
Any good suggestion / recommended implementation is welcome.


The easiest solutions are to either remove pkg_resources calls, or add
custom pkg_resources.py file that
loads the resource data without using setuptools metadata.


actually, even easier is to copy the full eggs into your app bundle by 
hand (by hand I mean code in your setup.py) -- a bit ugly, but it works.



The proper solution is to teach py2app how to copy eggs with their
metadata and resources into the
application bundle.


That would be nice, but I don't know that it's really the best solution.

I've dealt with this for an app that was heavily dependent on setuptools 
features like pkg_resources, and I think setuptools is really pretty 
ugly, at least when you want to use things like py2app and friends.


The assumption that you're packages are fully installed as part of a 
nice big python install is really built in, so the only solution is to 
copy huge chunks of stuff, much of which you don't need, into your app 
bundle -- whether py2app does this automatically, or you do it in your 
scripts, it's still a lot of extra stuff.


Personally, I like setuptools for install time stuff, but not so much 
for run time stuff -- if you can avoid run time calls to setuptolls, I 
would.


AS for resources, personally I like to use python files for data -- and 
then import to get it - this makes for nice, clean integeration with 
py2app, etc.


-Chris

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] windll on Mac?

[Chris Barker]

On 10/1/11 10:27 AM, Alex Hall wrote:

You said to find which windll functions are used. As far as I can
tell, here are all of them:
def ActivateWindow(hWindow):
KERNEL32 = ctypes.windll.KERNEL32
GetCurrentThreadId = KERNEL32.GetCurrentThreadId
USER32 = ctypes.windll.USER32
AttachThreadInput = USER32.AttachThreadInput
BringWindowToTop = USER32.BringWindowToTop
GetForegroundWindow = USER32.GetForegroundWindow
GetWindowThreadProcessId = USER32.GetWindowThreadProcessId
ShowWindow=USER32.ShowWindow
   #rest of function, using the above methods


You may get help on this from the wx list, but on this list, you'll 
probably need to figure out what these functions actually do, and how 
the results are used, to know how you would accomplish the same thing on 
a Mac.


-Chris





On 10/1/11, Chris Barkerchris.bar...@noaa.gov  wrote:

On 10/1/11 7:28 AM, Alex Hall wrote:

I just joined this list, so I am sorry if this is not the right place to
ask.
I have written an application in python, and one library I use relies
on the ctypes.windll functions, specifically user32 and kernel32. I
would like to use this library, but I also want to make my application
cross-platform. Is there an equivalent to windll on the Mac?


In a word, no.


It looks
like the library uses the dll for finding things like the current
thread id, current window, and for functions like window/thread
management (it is a dialog builder library built around wx).


These sorts of things will have to be done differently on the Mac. There
is some chance that some of them may be done with the wx lib (which
would wrap the Mac version), but most likely some will require
Mac-specific methods.

If you find out exactly what calls are made, and what they do, I'd ask
on the wxPython list, and then here, to find out how to do it on the Mac.

-Chris



   The

library can be found here:
http://www.empowermentzone.com/pylbc.zip
Thanks in advance for any information you can provide.




--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG







--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] windll on Mac?

[Chris Barker]

On 10/1/11 7:28 AM, Alex Hall wrote:

I just joined this list, so I am sorry if this is not the right place to ask.
I have written an application in python, and one library I use relies
on the ctypes.windll functions, specifically user32 and kernel32. I
would like to use this library, but I also want to make my application
cross-platform. Is there an equivalent to windll on the Mac?


In a word, no.


It looks
like the library uses the dll for finding things like the current
thread id, current window, and for functions like window/thread
management (it is a dialog builder library built around wx).


These sorts of things will have to be done differently on the Mac. There 
is some chance that some of them may be done with the wx lib (which 
would wrap the Mac version), but most likely some will require 
Mac-specific methods.


If you find out exactly what calls are made, and what they do, I'd ask 
on the wxPython list, and then here, to find out how to do it on the Mac.


-Chris



 The

library can be found here:
http://www.empowermentzone.com/pylbc.zip
Thanks in advance for any information you can provide.




--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] py2app wx.lib.pubsub.Publisher problem

[Chris Barker]

On 9/16/11 8:37 PM, Hyeonseung I wrote:

I`m trying to make an app bundle via py2app from a project using wxPython and 
it`s pub feature.
But there is a problem whenever running the app.

In my code, Publisher is imported as:
from wx.lib.pubsub import Publisher as pub


...


But when I run the app, error message is in a console:
ImportError: cannot import name Publisher



Publisher is an instance of wx.lib.pubsub.pub.PublisherClass
In other word, Publisher is NOT a module.
But in the app bundle, python try to regard 'Publisher' as module. WHY?


pubsub does some odd things in this regard.

There was a recent thread on the wxPython mailing list about this issue 
-- I think the pubsub author came up with a patch. In that case it was 
y2exe, but It's likely to be the same issue


You can also try the pubsub list.

-Chris




So, I tried to change my code:
import wx.lib.pubsub as ppp
pub = ppp.Publisher
..
pub.subscribe(self.OnImageUpdated, 'image.updated')
.

In this case, error massage is like this:
AttributeError: 'module' object has no attribute 'Publisher'

What`s the problem?

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG



--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Py2app zlib import error

[Chris Barker]

On 6/22/11 7:30 PM, Brian Zambrano wrote:

Just bumping this.  Does anyone have solution or some advice on how to
proceed?



The error is:

'import site' failed; use -v for traceback

...

zipimport.ZipImportError: can't decompress data; zlib not available


This looks like it has nothing to do with PyQT or anything else, 
actually, but is a raw py2app issue. So the first thing I'd do is try a 
really simple example. That will make it easier for others to try and 
reproduce the failure as well.


Taking a guess, I'd say you're getting a zlib from macports that may 
rely on something else in macports that other users don't have.


Again, I'd avoid macports for something you want to re-distribute.

-Chris



--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Getting an Error When Running App built with Py2app

[Chris Barker]

On 6/7/11 7:38 PM, Mike wrote:

Hi,
I built my python program using Py2app, using the default setup.py
script. I'm running Mac OSX Snow Leopard 64 bit.


which python are you using? Py2app is really expected to work right with 
Apple's built-in python (it can't include python itself)



ImportError:
'/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/wx/_core_.so'
not found


This looks like it's looking for wx in Apple's python.

I'd install the python from python.org, and try again with that. It's 
probably what you ultimately want anyway.


-Chris



--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Loading Python on my Mac

[Chris Barker]

On 1/12/2011 7:06 PM, s...@pobox.com wrote:


The resulting binary is in

 /usr/local/bin/python (non-framework version)
 /usr/local/bin/pythonw (framework version)

I'm sure others more knowledgeable about Python-on-a-Mac will correct any
mistakes I've made.


That all looks right. Note also that the installer should have added it 
to your PATH, so if you type:


python

at a command prompt, you should get it.

Using the Python.org binary is a good idea, as you get an up to date 
version, can re-distribute binaries (via py2exe) if you want, and most 
third party packages provide binaries for it (of at all).


good luck!

-Chris

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Python 2.7b2

[Chris Barker]

Ronald Oussoren wrote:

As you might know the second beta of python 2.7 was released last weekend. This is 
the first beta with macosx installers, they can be downloaded from 
http://www.python.org/download/releases/2.7/


great!, thanks Ronald.



There are two installers: one for OSX 10.3 or later and one for OSX
10.5 later. The 10.3 installer includes support for 32-bit CPUs,
while the 10.5 one supports 64-bit intel code as well.


so the 10.5+ one is:  PPC32, Intel32, Intel64 ?


-Chris


--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Module Import Problem

[Chris Barker]

Mike wrote:
 File build/bdist.macosx-10.6-universal/egg/pyttsx/__init__.py, line 
39, in init


this looks like you are running code out of the build dir, which may not 
have anything to do with your problem, but it's odd.


How are you running this, setting your paths, etc?

-Chris


 File build/bdist.macosx-10.6-universal/egg/pyttsx/engine.py, line 45, 
in __init__
 File build/bdist.macosx-10.6-universal/egg/pyttsx/driver.py, line 64, 
in __init__
 File build/bdist.macosx-10.6-universal/egg/pyttsx/drivers/nsss.py, 
line 18, in module
 File 
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/pyobjc_framework_Cocoa-2.2-py2.6-macosx-10 


.3-fat.egg/Foundation/__init__.py, line 8, in module
 File 
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/pyobjc_core-2.2-py2.6-macosx-10.3-fat.egg/ 


objc/__init__.py, line 22, in module
   _update()
 File 
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/pyobjc_core-2.2-py2.6-macosx-10.3-fat.egg/ 


objc/__init__.py, line 19, in _update
   import _objc
ImportError: 
dlopen(/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/pyobjc_core-2.2-py2.6-macosx-1 


0.3-fat.egg/objc/_objc.so, 2): Library not loaded: /usr/lib/libxml2.2.dylib
 Referenced from: 
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/pyobjc_core-2.2-py2.6-macosx-10 


.3-fat.egg/objc/_objc.so
 Reason: Incompatible library version: _objc.so requires version 10.0.0 
or later, but libxml2.2.dylib provides version 9.0.0



- Original Message - From: Aahz a...@pythoncraft.com
To: pythonmac-sig@python.org
Sent: Saturday, April 24, 2010 12:22 PM
Subject: Re: [Pythonmac-SIG] Module Import Problem



On Wed, Apr 21, 2010, Mike wrote:


My friend is testing my program for me on his Mac, he's running Snow
leopard. I'm using a package called Pyttsc that allows for text to
speech on the Mac. He's getting the following error:

file: build/bdist.macosx-10.6universal/egpyttsx/drivers/nsss.py, line 
18: no module named foundation


I looked into this, and it seems to be something related to
PyObjC. However, he tried import pyobjc and got no errors. Any idea
what the problem might be and how to fix it?


What's your OS?  What's the line of code generating this error?

Also, will this application build with py2app since it uses this 
package?


Theoretically, yes.  I'm a bit confused, because build/ implies that
you're already using py2app or some other distribution mechanism.
--
Aahz (a...@pythoncraft.com)   * http://www.pythoncraft.com/

It is easier to optimize correct code than to correct optimized code.
--Bill Harlan
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG 


___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG



--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Module Import Problem

[Chris Barker]

Mike wrote:
I don't think I'm doing anything special really. Just running it with 
python zgp.py. It may be something the pyttsx package is doing...


how did you install pyttsx ?

-Chris



- Original Message - From: Chris Barker chris.bar...@noaa.gov
To: pythonmac-sig@python.org
Sent: Sunday, April 25, 2010 12:14 PM
Subject: Re: [Pythonmac-SIG] Module Import Problem



Mike wrote:
 File build/bdist.macosx-10.6-universal/egg/pyttsx/__init__.py, 
line 39, in init


this looks like you are running code out of the build dir, which may 
not have anything to do with your problem, but it's odd.


How are you running this, setting your paths, etc?

-Chris


 File build/bdist.macosx-10.6-universal/egg/pyttsx/engine.py, line 
45, in __init__
 File build/bdist.macosx-10.6-universal/egg/pyttsx/driver.py, line 
64, in __init__
 File build/bdist.macosx-10.6-universal/egg/pyttsx/drivers/nsss.py, 
line 18, in module
 File 
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/pyobjc_framework_Cocoa-2.2-py2.6-macosx-10 
.3-fat.egg/Foundation/__init__.py, line 8, in module
 File 
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/pyobjc_core-2.2-py2.6-macosx-10.3-fat.egg/ 
objc/__init__.py, line 22, in module

   _update()
 File 
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/pyobjc_core-2.2-py2.6-macosx-10.3-fat.egg/ 
objc/__init__.py, line 19, in _update

   import _objc
ImportError: 
dlopen(/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/pyobjc_core-2.2-py2.6-macosx-1 
0.3-fat.egg/objc/_objc.so, 2): Library not loaded: 
/usr/lib/libxml2.2.dylib
 Referenced from: 
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/pyobjc_core-2.2-py2.6-macosx-10 
.3-fat.egg/objc/_objc.so
 Reason: Incompatible library version: _objc.so requires version 
10.0.0 or later, but libxml2.2.dylib provides version 9.0.0



- Original Message - From: Aahz a...@pythoncraft.com
To: pythonmac-sig@python.org
Sent: Saturday, April 24, 2010 12:22 PM
Subject: Re: [Pythonmac-SIG] Module Import Problem



On Wed, Apr 21, 2010, Mike wrote:


My friend is testing my program for me on his Mac, he's running Snow
leopard. I'm using a package called Pyttsc that allows for text to
speech on the Mac. He's getting the following error:

file: build/bdist.macosx-10.6universal/egpyttsx/drivers/nsss.py, 
line 18: no module named foundation


I looked into this, and it seems to be something related to
PyObjC. However, he tried import pyobjc and got no errors. Any idea
what the problem might be and how to fix it?


What's your OS?  What's the line of code generating this error?

Also, will this application build with py2app since it uses this 
package?


Theoretically, yes.  I'm a bit confused, because build/ implies that
you're already using py2app or some other distribution mechanism.
--
Aahz (a...@pythoncraft.com)   * http://www.pythoncraft.com/

It is easier to optimize correct code than to correct optimized code.
--Bill Harlan
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG


___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG



--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG 


___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG



--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] buildbots for OS X: G4 eMacs useful?

[Chris Barker]

Bill Janssen wrote:

I've got 3 eMacs just sitting around, and thought I'd deploy them as OS X
Python buildbots, if they'd be useful.  They're 1 GHz G4 machines,
with 640 MB of memory, running Tiger


If there is a need -- it would be great to keep one on Tiger -- it's a 
pain to build on leopard and have it work on tiger.


-Chris


--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Building 32-bit on Snow Leopard with tkinter/IDLE (was: Recommended Tcl/Tk with Py-2.6.x)

[Chris Barker]

Tom,

Thanks for the summary.

Tom Loredo wrote:

I should have added:  If you're happy with 32-bit Python on Snow Leopard
and have no need to build from source, just do as Chris recommended
earlier:  Use Python.org's installer.  It is built on an earlier OS
than SL and links against Apple's Tcl/Tk 8.4, so when you install
it on SL, it finds the 8.4 version that Apple includes in SL for
backward compatibility.


And also works with wxPython, MPL, scipy, numpy, and many many other 
third part packages.


-Chris


--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] C Extension Scipy/Numpy

[Chris Barker]

brennsuppa wrote:

I want to gain performance by using C for the computation of some arrays.
To do that I used this as a help:
http://www.scipy.org/Cookbook/C_Extensions/NumPy_arrays


I highly recommend that you use Cython instead:

http://wiki.cython.org/tutorials/numpy

It is much easier, and you are much more likely to make mistakes with 
reference counting, etc, if you do it by hand. Trust me on this.


With Cython, you can either do all your calculations with Cython, or 
have C routines that do the real work, and use Cython to call them. I'd 
do the former unless your C code is already written (and not trivial). 
In  either case, Cython can handle the conversion from python types to C 
types, and all the reference counting for you.




Now I want to wirte a subroutine for the calculations with several arrays.
But I don't know how to pass the arrays to the subroutine.

e.g. i have cin1, cin2, cin3, cin4 and cout

cout = do_anything(cin1, cin2, cin3, cin4)

and do_anything would be like:

double **do_anything(cin1[][n], cin2[][n], cin3[][n], cin4[][n])

for rows
for columns
add cin1,cin2,cin3,cin4
return value


Trivial in Cython -- in straight C,  you need to pass in the arrays as 
PyObjects, check if they are the type of arrays you want, and then get 
the pointers to the data blocks for you to pass to your c function.


Cython will do (almost) all of that for you.

-Chris


--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Framework does not get copied for standalone build: 0.4.3

[Chris Barker]

Kevin Walzer wrote:
 I wonder if the problem is with py2applet and the build script it

generates?


Maybe, you seem to be making this more  complicated than it should be. 
This should do it:


from setuptools import setup

APP = ['GridZilla.py']
DATA_FILES = []
OPTIONS = {'argv_emulation': True,
   'iconfile': './gzilla_ico_fin.icns',
   }

setup(
app=APP,
options={'py2app': OPTIONS},
setup_requires=['py2app'],
)

i.e. If you aren't using the system python, it should build a 
stand-alone, and you shouldn't need to explicitly include wx, and 
certainly not as packages and includes.


I'm not totally sure about yaml or report lab, but try without first.

-Chris



--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Framework does not get copied for standalone build: 0.4.3

[Chris Barker]

hari jayaram wrote:

In my several tests over the last few days. I can definitely say that
without forcing the standalone build , when I used the python from
python.org ( both 2.5.5 and 2.6.3) . py2app never created a standalone
build. It bundles the required libraries but never includes the system
python. That results in bundles that give a wx/_core_.so not dound
error.

This may be a Leopard feature with  the python downloaded from
python.org but without setting semi_standalone:False I never get a
standalone build withuprobably  these pythons and py2app.

If I use the very basic setup.py that Chris Barker mentioned. Then not
only do I not get the python built into the bundle . But the linking
is all messed up and I get the error.


I think those two are the same error -- it's trying to link relative to 
the python exe.


Anyway, it appears you've found a bug. What I'm not clear on is if it's 
working OK for anyone else on a 10.6 system -- if so, then I wonder what 
is different about yours? (sorry to question the obvious again, but are 
absolutely sure that you are running py2app with the python you think 
you are?)


This is going to take a bit of debugging. I think Ronald may be the only 
one that knows the guts of py2app at all, and I don't know if he's got 
the time, or can even duplicate the problem, so you may need to do it 
yourself -- or, if  you've got something working, maybe not bother!


If you do, try running it in a debugger, or simply sprinkling print 
statements around, and see if you can see why it's  getting confused 
about when to build stand-alone -- you may try grepping the source for 
standalone or something to find the relevant code.


Last note; even if you do need some of your tricks, you probably don't 
need to explicitly include wxPython, and certainly not as both 
packages and includes


good luck,

-Chris

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] check if wxpython has been installed properly

[Chris Barker]

Edward Moy wrote:
I seem to think that on Tiger, one needed to use pythonw to get GUI 
access (the regular python is just the plain command line tool, and the 
window server doesn't allow plain commands to access the GUI).  This was 
changed in Leopard so that either python or pythonw worked.



On Aug 20, 2009, at 10:47 AM, beegee beegee wrote:


hi guys i opened my terminal window on a mac os x tiger 10.4.11
and tried to do the following


does pyplot specify what versions of python and wxPython it needs?

Anyway, try typing 

python

then at the python prompt, type:

import wx

then

wx.__version__

and tell us what you get

And yes, you might try it with pythonw and see what you get.

-Chris

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] os 9.2

[Chris Barker]

Suresh Krishna wrote:

i have to work with mac OS 9.2 for legacy reasons...is there a
compiled version of python for this os ?


It looks like Jack Jansen's old page is still there, complete with 
downloads:


http://homepages.cwi.nl/~jack/macpython/download.html

Look for EasyDialogs, I think it's called, for simple GUIs. Also, 
TKinter worked, I think.


good luck!

-Chris
--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] module 'New' no in MacPython?

[Chris Barker]

Bill Janssen wrote:

There is a Python standard library module called new, and the Mac
filesystem is case-insensitive...  Try doing

   % touch new
   % touch New
   % ls


case-insensitive, yet case-preserving -- weird. apparently the case 
preserving does effect *nix apps like python. You can:

import new

but not:

import New

but if it's called new on other systems, why was the OP having problems?

Matthew O'Meara wrote:


Thanks for your quick response, It seems like the issue is due to
running python in an X11 terminal.  It seems to run fine through
Terminal.  I don't know if I'll dig into the problem, but that at
least gives me somewhere to look first.


Are you sure you're running the same python from the X11 terminal as 
from Terminal? is your PATH the same? Have you installed fink, macports, 
or some other python?


-Chris



--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

[EMAIL PROTECTED]
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Yet another problem with path

[Chris Barker]

Timothy Grant wrote:


While command lines can be made to lie, it concerns me that it looks
like you're using and Administrator account to do all this work.
Administrators have far to much power and can do far too much damage
far too quickly.


very true. However, OS-X be default does not allow anyone to log in as 
root. An Administrator is someone that is allowed to use sudo to do 
administrative tasks, so he's probably safe.


Do be careful with sudo though!

-Chris



--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

[EMAIL PROTECTED]
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] LXML with py2app

[Chris Barker]

Kenneth Miller wrote:

This is what I'm encountering.

Here i printed the sys.path, why does this include modules local to the 
machine? I want it to be independent of any local resources?
'/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5', 


This is Apple's installed python. by default, if you run py2app with 
Apple's system python, it will link to that, rather than embedding all 
of python with it.


I don't know if you can override that, but if you want your app bundle 
to run on pre 10.5 machines, you need to install the python.org python, 
and use that. py2app will embed the whole thing in your app bundle, and 
it should run on any max, OS-X 10.3.9 and above.


I don't know if there are any special issues with LXML, but I'd get a 
simple app with only the standard library working first, and then try 
your full app.


-Chris




--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

[EMAIL PROTECTED]
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] module 'New' no in MacPython?

[Chris Barker]

Matthew O'Meara wrote:

I'm trying to port a swig based application to run on OSX.  But it
seems that MacPython does not build the module 'New' by default


I haven't had any issues with SWIG on OS-X. I also have no idea what the 
module New is. Can you be more specific as to what exactly you are 
doing, and what errors you get?


You also may want to try on the SWIG list.

-chris


--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/ORR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

[EMAIL PROTECTED]
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Pythonmac-SIG] Accessing Resource forks

[Donna and Chris Barker]

HI all,

Somehow over all these years, I've managed to use Python on MAcs
without having it deal with resource forks and sll that -- but
ironically, not that we're all OS-X all the time, I need to do ti now.

What I'm trying to do is simple check for the existance of a resource
fork, and if it's there, the size.


This is what I've tried:

import Carbon.File as File
files = [junk.txt, junk_rsc.txt]

for filename in files:
f = File.FSRef(filename)
print file path is:, f.FSRefMakePath()

i = f.FSGetCatalogInfo(0)
print logical size is:, i[0].rsrcLogicalSize
print Physical size is:, i[0].rsrcPhysicalSize

In this case, junk.txt was created at the command line, so it
shouldn't have a resource fork. junk_rsc.txt I opened up in resedit,
which should have given it a small resource fork. Runnign this script,
I get:

file path is: /Users/cbarker/temp/AFP-SMB/junk.txt
logical size is: 65543
Physical size is: 30457855
file path is: /Users/cbarker/temp/AFP-SMB/junk_rsc.txt
logical size is: -593231776
Physical size is: -210763775

The paths are right, so it looks like I've got the FSRef right, but
rsrcLogicalSize and rsrcPhysicalSize make no sense.

How should I be doing this -- the docs are sparse, to say the least!

By the way, I might as well tell you the real goal, maybe one of you
will have a better idea.

We have a Windows file server that is about to be retired. over the
years, people of have put files on it using both the AFP and SMB
protocols (the server is running MS services for macintosh). These are
all mixed up. However, any file put up with one protocol loses it's
resource fork (and type and creator) if brought down with the other
protocol.

Our goal is to clean up this mess automatically.

The idea at hand is that a file brought down with AFP will either:

Have a nice resource fork, in which case it was put up with AFP, and we're happy
Have no resource fork, in which case it never had one, and we dont'
care what protocol was used, or it was put up with SMB, and we can
then bring it down that way instead.

The other obvious option is to look for the ._* files, which is where
the resource fork is stored with the SMB protocol. However, we're
concerned that that may not be reliable -- if a file were put up with
SMB, then replaced with AFP, there may be a ._* file, but it won't
work right. This actually seems pretty likely as while we have this
mixed system, there have been a lot of that didn't work, please put
the file back up with APF interations.

Thanks for your thoughts.

-Chris
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] readline support in ActivePython 2.4.2?

[Chris Barker]

Dave wrote:
  Chris,
 I did try to use those notes

Those notes specifically addressed how to statically link the extra 
libs, so you probably missed something, which is probably because I 
didn't write them very clearly.

  I posted
 a question with the error report on matplotlib-users

I saw that, but had no time to help right then.

I compiled/installed versions of freetype and libpng but I'm not really
sure if or how to get matplotlib to find them.

/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packag=
es/matplotlib/ft2font.so:
Symbol not found: _vsprintf$LDBLStub
 Referenced from:

/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packag=
es/matplotlib/ft2font.so

 It was late night when I originally posted this but now I can guess what it
 might mean.  Is ft2font.so the actual name of the binary freetype library
 file?

That's an MPL compiled module that should have been created during the 
build, and it looks like it was.

  And let me guess, I need to drag a file with that name into
 site-packages/matplotlib? 

It should be there already. If not, something went wrong with the install.

 In general will unix apps that need libraries find them if they are found on
 your $PATH or are they hard-coded to look somewhere specific.

no, they look for them in the dynamic library path. On Linux, this is 
defined in /etc/ld.conf. I'm not sure about OS-X. In this case, I think 
you're right, it's looking for the freetype libs, and not finding them. 
I'm not sure where they should be, or how to add to the path OS-X looks 
for them in.

  I keep
 running into library and path issues again and again on unix systems.

I've and fewer of them than on Windows!.

My solution was to build MPL against the static libs. It shouldn't be 
necessary for your own system, but it makes it a lot easier to 
distribute, and does get rid of the Path issues one you've got it built.

I'll spend a few minutes messing with it now, but I don't' actually need 
it right now, so I won't put in much time.

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer

NOAA/ORR/HAZMAT (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

[EMAIL PROTECTED]
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fwd: Preferred IDE

[Chris Barker]

Jeffrey E. Forcier wrote:
 I also seem to remember BBEdit not having that  
issue for some reason, but it wasn't worth the price tag for that  
one tweak.

 TextWrangler/BBEdit is an *excellent* editor, so be sure to try it out 
 yourself

Yes, it is, but it really doesn't do python indenting quite right. These 
days, all python code really should be indented with 4 spaces, and while 
you can set BBedit to put in 4 spaces when you hit the tab key, it 
doesn't recognize those four spaces as a single level of indentation 
when you want to delete them, requiring four hits of the backspace key.

One would think that this is a minor annoyance, and perhaps it is, but 
being used to the excellent [X]emacs python mode, I find it very 
frustrating.

A few years ago, there was a thread in this mailing list about his, and 
someone had even discussed the issue with BB's tech support. Their 
response was something along the lines of you shouldn't want to do 
that, and they therefor will not try to support it. Granted, I'm sure 
Python coders are a pretty small part of their market, and indentation 
based languages are few and far between, but at the core was an attitude 
that they know better than we do what we should want, and even more of 
an issue, they are in total control of what will and won't be added to 
BBedit. One reason I don't like closed source software. However, besides 
being closed source, BBedit does not provide a powerful way for users to 
  customize the editor's behavior themselves. If they did we'd have an 
excellent python mode by now.

Side note: does anyone know how to do selection, cut and paste by 
columns in BBEdit?

The only reason I like [X]emacs is that it has a full-featured mode for 
every kind of text file I've ever needed to edit, and it has all those 
modes because users could write them. There is no way the core 
development team could ever support everything, and everything well for 
that matter.

I'm still looking for a nice modern, platform independent, general 
purpose, fully customizable (preferably in Python) text editor. SPE is 
heading that way, and Pepper (http://digitalwandering.com/) still has 
promise.

Does anyone know how customizable jedit is .. in Jython maybe?

Sorry for the rant

-Chris









-- 
Christopher Barker, Ph.D.
Oceanographer

NOAA/ORR/HAZMAT (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

[EMAIL PROTECTED]
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Selecting in BBEdit Python Indenting style (spaces)

[Chris Barker]

Louis Pecora wrote:

 You hold down the option key while selecting, but you cannot do this
 in the soft wrap mode.  You have to set the window to hard wrap at
 some column number.  If you have the BBEdit manual, you can find more
 info around page 52 or just look in the index.

thanks.


 What the heck were they (Guido?) thinking when they used 4 spaces as
 the one true mode of indentation for Python?

I have no clue. It was a bad idea, from the beginning, to allow mixed 
tabs+spaces. (I still don't understand why that hasn't been completely 
deprecated).

 I would think that TAB would be infinitely better and avoid the
 problems you point out that probably plague a lot of editors when
 doing Python code.

I agree. Tabs would be easier in most cases, but:

 And many editors allow you to set the size of the
 TAB (e.g. 2 spaces in size if you think 4 looks too large -- I do).

Well, that is an issue. I think there is a trade off between people 
making their own choice about what things should look like and 
consistency. Also, aside form changing the size of tabs, various places 
people use text, like in email messages, html, etc, tabs get mangled, so 
that may be why spaces were selected as the standard. Or maybe there is 
no logic, and it's just what Guido likes.

As it happens, the Mac is the only place I've ever had a problem, both 
in the old macPython IDE and BBedit. All other editors I've used (at 
least mildly competent ones) have been fine.

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

NOAA/ORR/HAZMAT (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

[EMAIL PROTECTED]
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Interactive shell

[Chris Barker]

I've never been able to figure out when to use .profile vs .bashrc, but 
I thought it had to do with only one of them being run when a subshell 
was started, or something like that.

I do note that on both my OS-X and Linux boxes, /etc/profile sources 
bashrc, and uses bash syntax, so it sure looks like a bash-specific 
config file to me.

-Chris

[EMAIL PROTECTED] wrote:

 I'd use '.bashrc' or '.bash_profile', because 'export' is bash syntax -- 
 '.profile' should be read by any shell, and tcsh (e.g. default in OSX 10.2) 
 doesn't understand that.
 BTW this file lives in you home folder (~ = /Users/yourname).

-- 
Christopher Barker, Ph.D.
Oceanographer

NOAA/ORR/HAZMAT (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

[EMAIL PROTECTED]
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Building Pthreads Statically (slightly off topic)

[Chris Barker]

Samuel M. Smith wrote:
 I am building python on an embedded linux box. I tried to sign up for  
 the comp.lang.python mailinglist

Just so you know,

It's also a newsgroup, so you can get to it with a regular usenet client 
and/or other systems like google groups.

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

NOAA/ORR/HAZMAT (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

[EMAIL PROTECTED]
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig