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

[Christopher Barker]

Thanks Jack, this sounds like a promising lead.

In this case, it seems to be PyOpenGL, ultimately loading a system dynlib.
But the broken bit may be within my control.

I’ll report back if I figure it out.

-CHB

On Fri, Jan 7, 2022 at 3:40 PM  wrote:

> I googled the "file system relative paths not allowed in hardened
> programs” and the results made me remember a similar issue I have seen
> recently.
>
> I was loading a dylib through ctypes, and suddenly this stopped working.
> The problem eventually turned out to be that another dylib (a dependency of
> the dylib I was loading) had its quarantine flag set. That was never a
> problem before, but suddenly (last summer?) it has started to be a problem.
>
> The solution turned out to be to run `xattr -d com.apple.quarantine
> blablabla.dylib` on the problem library.
>
> Not sure whether this is your problem or not, but it’s worth a shot. If
> (big if) this is a dynamic loader problem you’re in for a hard time: it
> used to be possible to debug these by setting the various DYLD_ environment
> variables to “look over the shoulder” of the dynamic loader to see what it
> is doing, but nowadays these environment variables are always cleared
> automatically (unless you have the
> com.apple.security.cs.allow-dyld-environment-variables entitlement, so if
> there’s a third party app somewhere in the chain that’s a no-no).
> --
> Jack Jansen, , http://www.cwi.nl/~jack
> If I can't dance I don't want to be part of your revolution -- Emma Goldman
>
>
>
> > On 6 Jan 2022, at 19:57, Chris Barker via Pythonmac-SIG <
> pythonmac-sig@python.org> wrote:
> >
> > 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-6

Re: [Pythonmac-SIG] Problems building a binary from cpython that can be installed in /Users/{USER}/Library

[Christopher Barker]

 a bunch of files including the .app bundle.
>
> There may be a bit too much complexity but have look at how I build the
> .app bundle in
>
> https://github.com/barry-scott/BarrysEmacs/blob/master/Editor/PyQtBEmacs/build-macosx.sh
> <https://github.com/barry-scott/BarrysEmacs/blob/master/Editor/PyQtBEmacs/macosx.mak>
> and
>
> https://github.com/barry-scott/BarrysEmacs/blob/master/Editor/PyQtBEmacs/brand.setup-macosx.py
>
> I'm using PyQt not Tk.
>
> Barry
>
>
>
>
> Thanks for reading through all this!
>
>
> =
>
> PS: Contents of my .../Universal/other-sources directory:
>
> -rw-r--r--   1 admin  staff367573 Nov 10 00:53
> ncurses-5.9-20120616-patch.sh.bz2
> -rw-r--r--   1 admin  staff   2826473 Nov 10 00:53 ncurses-5.9.tar.gz
> -rw-r--r--   1 admin  staff   9834044 Nov  9 22:19 openssl-1.1.1l.tar.gz
> -rw-rw-rw-@  1 admin  staff   2956627 Nov 10 01:06
> sqlite-autoconf-3350500.tar.gz
> -rw-rw-rw-@  1 admin  staff  10259009 Nov  9 22:55 tcl8.6.11-src.tar.gz
> -rw-rw-rw-@  1 admin  staff   4496914 Nov 10 00:37 tk8.6.11-src.tar.gz
> -rw-rw-rw-@  1 admin  staff   1490665 Nov 10 00:45 xz-5.2.3.tar.gz
>
> =
>
>
> Paul Romer
> p...@paulromer.net | paulromer.net | @paulromer
> <https://twitter.com/paulmromer?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor>
>
> ___
> 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 maillist  -  Pythonmac-SIG@python.org
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
>


-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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] py2app: Can successfully create app with alias mode but version built for deployment returns an error message

[Christopher Barker]

On Thu, Jun 17, 2021 at 9:24 AM  wrote:

> I think `.pyx` files are Cython sources,
>

Yes, they are. But Cython is designed to show the source line number when
there are errors. So this has been compiled.

That error is vaguely familiar to me, I got it recently— I think the fix
was to clean out and recompile the Cython files.

However, if Pandas is working outside py2app, then it did get built
properly.

I’d look at the app bundle and see what’s different from the regular
install.

Ideally, it would copy only the complied modules.

-CHB


and I think these need to be compiled on installation (which should have
> happend during py2app?).
>
> When you google for “pandas py2app” you’ll find people reporting similar
> (but not identical) problems to what you report.
>
> But note that some of the stuff google finds is very old, so use your
> common sense, the world may have changed a lot since the link was written.
>
>
>
> On 15 Jun 2021, at 23:37, Paul Fishback  wrote:
>
> I'm using Python 3.9 on a Mac running Big Sur and am trying to create an
> app, MyApplication.app, from a script using py2app. I'm following the
> process outlined at https://py2app.readthedocs.io/en/latest/tutorial.html .
> The app itself uses tkinter for creating a GUI. My setup file looks like
> the following, where 'background.png' is an image that appears on the
> screen at program startup, and 'pandas' and 'cmath' are included due to
> previous error messages:
>
> from setuptools import setup
>
> APP = ['MyApplication_6_14.py']
> DATA_FILES = []
> OPTIONS = {'resources':['background.png'],'packages': ['pandas','cmath']}
>
> setup(
> app=APP,
> data_files=DATA_FILES,
> options={'py2app': OPTIONS},
> setup_requires=['py2app'],
> )
>
> I can create and run the application in alias mode, and no error messages
> arise when I build for deployment. However, when I attempt to run the
> deployed version from the command line via,
>
> ./dist/MyApplication.app/Contents/MacOS/MyApplication
>
> I receive a fairly lengthy error message below, where Python_May_2021 is
> the file location:
>
> fishbacp@fishbacpK0ML85 Python_May_2021 %
> ./dist/MyApplication_6_15.app/Contents/MacOS/MyApplication_6_15
> Traceback (most recent call last):
>   File
> "/Users/fishbacp/Desktop/Python_May_2021/dist/MyApplication_6_15.app/Contents/Resources/__boot__.py",
> line 115, in 
> _run()
>   File
> "/Users/fishbacp/Desktop/Python_May_2021/dist/MyApplication_6_15.app/Contents/Resources/__boot__.py",
> line 84, in _run
> exec(compile(source, path, "exec"), globals(), globals())
>   File
> "/Users/fishbacp/Desktop/Python_May_2021/dist/MyApplication_6_15.app/Contents/Resources/MyApplication_6_15.py",
> line 6, in 
> import pandas as pd
>   File
> "/Users/fishbacp/Desktop/Python_May_2021/dist/MyApplication_6_15.app/Contents/Resources/lib/python3.9/pandas/__init__.py",
> line 179, in 
> import pandas.testing
>   File
> "/Users/fishbacp/Desktop/Python_May_2021/dist/MyApplication_6_15.app/Contents/Resources/lib/python3.9/pandas/testing.py",
> line 5, in 
> from pandas._testing import (
>   File
> "/Users/fishbacp/Desktop/Python_May_2021/dist/MyApplication_6_15.app/Contents/Resources/lib/python3.9/pandas/_testing.py",
> line 29, in 
> import pandas._libs.testing as _testing
>   File "pandas/_libs/testing.pyx", line 1, in init pandas._libs.testing
> ValueError: source code string cannot contain null bytes
>
> I'm curious to know if anyone has insights regarding the last line in the
> above message.
>
> Thanks
>
> PaulF
> --
> Professor of Mathematics, Grand Valley State University
> Past-President, Pi Mu Epsilon National Honorary Mathematics Society, Inc.
>
> Department of Mathematics (MAK C-2-408)
> Grand Valley State University
> 1 Campus Dr.
> <https://www.google.com/maps/search/1+Campus+Dr.+Allendale,+MI+49401?entry=gmail=g>
> Allendale, MI 49401
> <https://www.google.com/maps/search/1+Campus+Dr.+Allendale,+MI+49401?entry=gmail=g>
> fishb...@mail.gvsu.edu
> 616.331.2040
> 616.331.3120 (fax)
> ___
> 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 maillist  -  Pythonmac-SIG@python.org
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
>
-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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] "pythonw" in a Unix build

[Christopher Barker]

On Mon, Jan 18, 2021 at 4:33 PM Jack Jansen  wrote:

> it still isn't clear to me _why_ you wouldn’t want to use a framework
> build…
>

on a personal level, it's because the conda folks really want to use a
plain vanilla unix build -- and I want things to work with conda.

As to why conda wants to do that, my thoughts:

conda manages not just Python, but also a full set of other libraries, and
even other languages (R, Julia, Java).

In that way, it's a bit like homebrew or macports.

However, It also tries to be as platform-neutral as possible, so anything
that works one way on conda works that same way on all platforms.

And in practice, it solves a LOT of problems, problems that were a pain in
the neck for years on the Mac.

Also in practice, treating OS-X as "just another unix" works quite well in
almost all ways -- there are a few addicted here than there, though those
are mostly about clang than OS-X per se. But most things "just work".


> The whole exercise feels a bit like discussions from 15 years ago, with
> Unix wizards who wanted MacOS to behave as if it was plain vanilla Unix
> without all the things Apple changed. And that is much less true today than
> it was then…
>

Another practical consideration is that the vast majority of Python
developers that use Macs use them like a Unix system: data analysis, web
development, etc, etc. It's only desktop GUI software that poses any
issues, and this is the only issue (that I know of) for that.

There was an experiment with using a Framework build in conda a while back
-- it immediately ran into the issue that it would be incompatible with all
existing conda-python packages, so that's not good. It could be that that
could be addressed with appropriate symlinks, but not one did a thorough
testing.

Another issue is that conda now supports platform-independent Python
packages -- and that would get a lot harder with a Framework build. (though
again, maybe a full set of links could solve that)

It's also the case that using a Framework build inside conda buys us
absolutely nothing -- it just makes things gratuitously different from the
other *nix systems for no gain. I appreciate the idea of frameworks, but a)
I don't think Frameworks were really designed for things like python
anyway, and b) conda is solving all the problems that Frameworks solve but
-- in a different, and platform independent way.

In short: building python as a framework in conda would create an
incompatibility with no gain. The only reason to do it would be to get the
"pythonw" executable, and that doesn't actually require a Framework --
"just" some new build scripts.

Anyway, if the folks that want this do the work, it looks like it can
happen, and if not, then I guess we won't get it.

Fair enough.

-Chris


On  18-Jan-2021, at 18:38 , Christopher Barker  wrote:
>
> On Mon, Jan 18, 2021 at 1:34 AM Ronald Oussoren 
> wrote:
>
>> As mentioned on python-dev adding the “pythonw” functionality to the unix
>> build is not very hard. I expect that integrating with the build system
>> (Makefile/configure script) will be the hardest part due to introducing
>> different behaviour for the macOS platform.
>>
>
> Thanks Ronald, that confirms my suspicions that this is really an autoconf
> issue. Which makes it an utter mystery to me :-(
>
>> And we already have a work around in the core python code, it's just that
>> the build system needs to be set up to build it outside of a Framework.
>>
>> The framework build does not have a workaround for these problems, it has
>> a proper solution ;-).
>>
>
> Glad to hear that -- in earlier conversations, I got the impression that
> you thought the executable wrapper was kind of a hack :-).
>
> Anyway -- if any of you have autoconf expertise and the inclination, I'd
> love to see this get done, and would be glad to help as best I can.
>
> -CHB
>
> --
> Christopher Barker, PhD (Chris)
>
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython
>
>
> --
>
> Jack Jansen, , http://www.cwi.nl/~jack
>
> If I can't dance I don't want to be part of your revolution -- Emma Goldman
>
>
>
>

-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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] "pythonw" in a Unix build

[Christopher Barker]

On Mon, Jan 18, 2021 at 1:34 AM Ronald Oussoren 
wrote:

> As mentioned on python-dev adding the “pythonw” functionality to the unix
> build is not very hard. I expect that integrating with the build system
> (Makefile/configure script) will be the hardest part due to introducing
> different behaviour for the macOS platform.
>

Thanks Ronald, that confirms my suspicions that this is really an autoconf
issue. Which makes it an utter mystery to me :-(

> And we already have a work around in the core python code, it's just that
> the build system needs to be set up to build it outside of a Framework.
>
> The framework build does not have a workaround for these problems, it has
> a proper solution ;-).
>

Glad to hear that -- in earlier conversations, I got the impression that
you thought the executable wrapper was kind of a hack :-).

Anyway -- if any of you have autoconf expertise and the inclination, I'd
love to see this get done, and would be glad to help as best I can.

-CHB

-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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] "pythonw" in a Unix build

[Christopher Barker]

On Thu, Jan 14, 2021 at 3:14 PM Jack Jansen  wrote:

> For example, the brew Python is installed into a framework tucked away
> deep in /usr/local/Cellar but you don’t notice this at all: you can just
> use “python foo.py” and the moment the script does GUI calls it’ll get an
> icon in the doc and all that.
>
> What problem are you trying to solve?
>

It's interesting that brew python has decided to use a Framework build 

But the problem at hand is conda python which used a plain unix build.

They have provided a shell script "pythonw" that re-directs to a python
inside an app bundle, and that works OK on the command line, but it does
not work with, e.g. setuptools entry points.

I could dig up the threads, but this has been discussed on this list, and
few gitHub issues.

In short, there are a few ways to work around these issues, but no one (the
conda people, the setuptools devs) wants to put the kludgy work around in
their code.

And we already have a work around in the core python code, it's just that
the build system needs to be set up to build it outside of a Framework.

-CHB




> Jack
>
> On  14-Jan-2021, at 23:07 , Chris Barker via Pythonmac-SIG <
> pythonmac-sig@python.org> wrote:
>
> 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
>
>
> --
>
> Jack Jansen, , http://www.cwi.nl/~jack
>
> If I can't dance I don't want to be part of your revolution -- Emma Goldman
>
>
>
> ___
> 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, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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] Using Python on Mac

[Christopher Barker]

it looks like vPython (I'm assuming vPhython was a typo) is fairly up to
date:

https://vpython.org/presentation2018/install.html

as is pyserial:

https://pypi.org/project/pyserial/#history

I would go with vPython's advise to use conda to get both vPython and
pyserial.

-CHB

(note: I recommend "miniconda" -- and then install exactly what else you
need)



On Wed, Dec 30, 2020 at 3:51 AM Jack Jansen  wrote:

> Guido,
> if I googled correctly that “Python and Arduino” series is from 2014. At
> that time there was something to be said for using Python 2.7, but in 2020
> that is no longer true. And, actually, since Python 2.7 has finally been
> moved to end-of-life last year many tutorials that refer to Python 2.7
> specifically will stop to work (as you have found out).
>
> Your best bet is to ignore all the version numbers Paul McWorther mentions
> in his tutorial, and try to download the latest version of everything. See
> how far that gets you.
>
> You’re not the first one to run into this problem, as you can see from the
> comments under the video, but unfortunately none of the people that came
> across the Python 2.7 issues added comments saying what they had to do to
> run the tutorial in 2020. If you get it to work: maybe add a comment to the
> video to say what you had to change to make it work?
>
> And feel free to post problems here,
>
> Jack
>
> On  29-Dec-2020, at 19:29 , Guido Deboeck  wrote:
>
> In Lesson 2 of Python and Arduino by Paul McWhorter he suggest downloading
> Python 2.7 rather than the more recent version 3.x. He also suggests to
> download pyserial 2.7 as well as vPhython. I have search for pyserial 2.7
> and have not been able to find it on the web As to vPhython I found
> PyCharm, but that is not for free. Could you pls help me to find pyserial
> 2.7 as well as vPhython for use on a Mac. Thank you.
>
> ___
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
>
>
> --
>
> Jack Jansen, , http://www.cwi.nl/~jack
>
> If I can't dance I don't want to be part of your revolution -- Emma Goldman
>
>
>
> ___
> 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, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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] py2app questions

[Christopher Barker]

On Mon, Dec 14, 2020 at 11:28 PM Timothy M. Shead <
t...@shead-custom-design.com> wrote:

> > How was Python build?
>
> The Python executable and all dependencies are installed using Conda:
>
> Python 3.8.5 (default, Sep  4 2020, 02:22:02)
> [Clang 10.0.0 ] :: Anaconda, Inc. on darwin
>

Note that the conda build of Python on OS-X is a "plain *nix" build. which
may be the source of your issues. I'm not sure what the difference is other
than the app bundle wrapper (pythonw), but I wouldn't be supposed if
there's a difference that will break py2app.

HTH,
 -CHB



> >> And when I look at the main executable, the second rpath looks
> questionable:
> >>
> >>$ otool -l dist/hello.app/Contents/MacOS/hello
> >>…
> >>Load command 16
> >>  cmd LC_RPATH
> >>  cmdsize 32
> >> path @loader_path/../lib (offset 12)
> >>Load command 17
> >>  cmd LC_RPATH
> >>  cmdsize 48
> >> path @loader_path/../../../../../ (offset 12)
> >
> > Was this file created by py2app, or did you change it afterwards?  The
> stub executable in current releases of py2app should not contain LC_RPATH
> entries at all.
>
> This is the executable built by py2app, with no meddling from me:
>
> $ rm -rf build dist
> $ python setup.py py2app
> $ otool -l dist/hello.app/Contents/MacOS/hello
>
> >> What is the right approach to address this?  Manually copy the missing
> .dylib files into dist/hello.app/Contents/lib?  I’m too new to know what to
> expect from py2app, but I’m surprised that it would be necessary for
> something as ubiquitous as zlib?
> >
> > Py2app, or rather the macholib library used by py2app, does not process
> @rpath correctly. The code is older than the introduction of this feature
> and is not easily adjusted for it because some information needed for
> correctly dealing with @rpath and @loader_path is lost before the code that
> should use the information is active.  I have rewriting that code on my too
> long todo list.
> >
> > Note that this works for me, with the Python.org installation of Python.
>
> Many thanks,
> Tim
>
> ___
> 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, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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] Building plans .....

[Christopher Barker]

> Does this force the use of conda on macOS python users?

Absolutely not.


> Or is it just asking for a build option that is conda friendly?
>

That’s it exactly. I would think it would be friendly to other use cases,
but the default Python.org builds are a different use case, and should be
built in a way that’s appropriate for those users.

I have been happy use the python.org builds and py2app + PyQt5.
>

Exactly— I’m not suggesting anything change for folks like you.

-CHB


-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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] Building plans .....

[Christopher Barker]

On Mon, Mar 16, 2020 at 3:55 PM Jack Jansen  wrote:

but "conda" is a package management tool, a bit like yum or apt in the
Linux world, or Brew, for that matter. except that:

* It provides management of isolated "environments", so you can have a
different collection of software and libraries, all with a different
combination of version on the same system, isolated from one another.

So how does conda handle things that must be installed in “special”
> locations on some platforms? For example, if you install some package that
> contains a kernel driver, undoubtedly on windows this’ll have to go
> somewhere deep down in c:\system32 or something.
>

I expect that answer is "it doesn't" -- it's really not intended to support
things like kernel drivers. The point of conda is not just package
management, but  the ability to create isolated environments, with specific
versions of various inter-dependent packages.

An environment is essentially a directory tree with a loto f familiar (to
the *nix folks, anyway) directories. Here's what's in my primary working
environment, for example:
$ ls
binphrasebooks
conda-meta plugins
docqml
etcqsci
includeresources
libsbin
libexecshare
manssl
mkspecstranslations

When you "activate" an environment, it sets up a bunch of environment
variables so that those "Versions" are found first. Here's $PATH by my
primarily working environment (called py3) is activated:

$ echo $PATH
/Users/chris.barker/miniconda3/envs/py3/bin:/Library/TeX/texbin:/Users/chris.barker/miniconda3/condabin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/sbin

It prepended the bin dir from the Environment on there. It does similar
things to all the other env variables.

Because in a way Python on the mac (if you want to use a
> framework/app/bundle Python) is like that: it has some platform-specific
> installation requirements (that bits of it go into /Library/Frameworks and
> other bits in /Application), and in the end you setup a few symlinks in the
> conda bin directory (or the conda per-environment bin directory, or however
> that works) and for a conda user the situation will be exactly the same on
> Mac as on Linux…..
>

So yes, you could install the entire Framework inside the environment, and
then have the various links to the "expected" places inside that
environment (conda uses relative paths wherever possible, so it wouldn't be
hard). And probably, it would end up looking just like a *nux install as
far as everything else is concerned, except for that extra Framework thing
in there somewhere that could be ignored.

I'm not sure why the conda folks decided not to do that in the first place,
but they didn't, and no one seems to want to do it now.

I suppose I could set it up and submit a PR and see what folks think, but
the big question is: what does a Framework Build by conda? ANd I think the
answer is nothing, except that we already know how to build the pythonw
executable that way.

-Chris
-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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] Building plans .....

[Christopher Barker]

On Mon, Mar 16, 2020 at 1:09 AM Georg Seifert  wrote:

> > - A framework build is easier to integrate into applications that are
> built using Xcode (just drop the framework into list of used frameworks)
> > When would that come into play? If you are developing an application
> that embeds the python interpreter? OR if you are using XCode as your IDE
> for developing a Python App?
> >
> I’m using that in my app (written in ObjectiveC) to be able to run python
> scripts inside the app and to load plugins that are written in python but
> don’t bring there own python interpreter.
>

Perfect -- and that's using Python more as a "library". So providing a
Framework build is a good thing for these uses. Though I wonder if there's
a need for a pre-built one with an installer --wouldn't folks using XCode
be able to built it themselves? But either way, this isn't a use case for
conda, or brew or 

Also, there's no reason that a "PythonFramework" couldn't be a
separate package in conda -- you just wouldn't want to have all the other
Python-y stuff depending on it. If you are embedding the interpreter, you
are managing all the the dependencies anyway.

Now someone just needs the time to do it :-(

-CHB

-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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] Building plans .....

[Christopher Barker]

On Sun, Mar 15, 2020 at 4:39 AM Ronald Oussoren 
wrote:

> AFAIK the only difference for this discussion is the “Python.app” trick,
> and that can be accomplished outside of a framework build as well (but
> currently is not).
>
> Two other differences:
> - A framework build is easier to integrate into applications that are
> built using Xcode (just drop the framework into list of used frameworks)
>
When would that come into play? If you are developing an application that
embeds the python interpreter? OR if you are using XCode as your IDE for
developing a Python App?


> - py2app currently doesn’t work properly with a Unix build
>

But that could be fixed, yes? (And I think PyInstaller already does work
with a unix build)

I *think* this means that a unix-style build with the python.app "trick"
would be appropriate for use in distributions that are otherwise not "mac
native" -- e.g. conda, homebrew.

As to whether a style build would be OK for the python.org installer, I'm
not so sure. That may still be a candidate for a Framework build --it sure
does make installation/uninstalling easier than scatter files all over
/usr/local.

Of course, to make any of this happen, someone with the autoconf skills
needs to have the time and motivation to do it. I'm not that person (though
who knows how far I would have gotten if I'd spent the time I've spent
talking about this actually giving it a try :-) )

So we'll see. Maybe there's no one that both wants this done and has the
time and skills to do it -- such is the world of open source.

-CHB




> Ronald
>
> —
>
> Twitter: @ronaldoussoren
> Blog: https://blog.ronaldoussoren.net/



-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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] Building plans .....

[Christopher Barker]

, but aren't writing code specifically for the Mac )


> Here I don’t mean people who don’t develop at all (because then they
> wouldn’t need Anaconda) but who are basically data scientists or deep
> learning people or whatever, and who have been told that there’s a nifty
> package in Python that’ll do just what they need. And for them I think you
> need to look at how Anaconda treats the difference between Windows and
> Linux: if it tries to hide that difference as much as possible (like
> jupyter does, for example, but also completely different things like Adobe
> CS which really tries to make their software look that same independent of
> platform) you should do the same.
>

That's exactly what Anaconda (the distribution) does now. It tries to be as
consistent across platforms as it can. But that doesn't mean it doesn need
MAc features at all -- it provides a number GUI programs (including it's
own application manager) I think these are mostly written using QT, so are
not terribly MAc-native, but they need to run.

And if you can’t decide: how much work would it be to have two Anaconda
> distributions for the Mac:
> - one that is primarily Unix-y, installed through brew, intended to be
> used from the command line, and with the MagicMacPythonWrapper
>

See above -- no none would install Anaconda (or conda) via brew. conda is
pretty much a replacement for brew.


> - another one that is framework-based, installed as an app bundle, signed,
> notarized, all that jazz, and comes with an “Anaconda Terminal” which is a
> perfectly normal Terminal but with all the environment and things setup so
> that people can use the command line in the Unix way but it would under the
> hood have all the PATH and DYLD_LIBRARY_PATH and whatnot to use the Python
> from the accompanying framework build always.
>

This is pretty much what Anaconda is now, but without the Framework-specifc
stuff -- and it does work.

And I don't think there would ever be two "Anacondas"

In theory, you could have two different Python packages for conda: python_u
and pyrthon_f. But I think that would create a nightmare for all the
dependent packages -- anything that required, say, python3.8 may have to be
built differently depending on which python build you had. It's possible
that that could be worked around with a lot of symlinks, so that they would
appear to tbe the same. But if that can work, then why not simply have one
build anyway.

Which reminds me of a reason not to use a Framework build for conda: You
can now have "noarch" packages -- if the contents of the code is the same
for all platforms (like a typical pure python package) then you can have a
single package that can be used on all platforms. Which means that the
directory layout  has to be the same everywhere. Which maybe could be
accomplished with symlnks, but it would be a bit of a mess.

Anyway, I think that the conda use case defined above would be well
suppoted by essentially a standard *nix build, but with the executable
redirecting to inside an app bundle trick.

That would also work fine for the "Unix folks" -- for brew and the like.

The only question I'm not sure on is if it would work for the
point-and-click-install on the MAc use-case -- that use case may best be
served by the Framework build and installer that we already have.

- Chris


-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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] Building plans .....

[Christopher Barker]

Jack et al,

Yes, lots of deja vu here as well -- I suppose because this hasn't been
resolved.

> Hmm, that was a long sentence for what was intended to be the question:
“What is the problem with using a normal MacOS Framework build of Python
for Anaconda”?

I can't really answer this -- I was not part of the original discussion,
nor am I in an decision making position now. I'm just a user an contributor
to conda-forge that's trying to make things easier.

But I think it more or less comes down to what you said:

Conda wants to be as similar as possible on all platforms as it can. Yes,
there are differences on Windows, but they are keeping those to a minimum,
and there is no choice.  OS-X, on the other is, as you mentioned, BSD *nix.
So doing something very differently there feels gratuitous.

And in a practical sense, many folks use OS-X as a development platform, so
want to use Python on OS-X in the same way they use it on other *nix
systems. I myself have found this to be very helpful for my own work, as
well as for teaching. And if you aren't doing any GUI work, then it is nice
for the Mad to be "just another *nix". For my part, I develop for the MAc,
but only in the context of cross platform tools: I never do anything you
can do only on the Mac, and try to do everything in a cross platform way as
possible (using wPyrthon for the GUI, for instance). Which is why I want
Python, and everything else to work the same .

That being said, I'm not sure that this was thought through all that
carefully initially, and I haven't seen anyone spell out the reasons for
not doing a Framework build other than

"Honestly, I think adding the framework will make this more confusing when
building things between OS X and Linux" (from
https://github.com/conda-forge/python-feedstock/issues/23).

But I'll turn around the question: "What is the problem with using a
non-framework build for conda on the Mac" (or even outside of conda,
e.g.brew or macports)

It's unclear to me is what the advantages of a Framework Build are in this
context. Other than it being the "Mac way of doing things". It's my
impression that Apple simply has not thought out how it should support
things like Python -- the whole system is very much designed around
"Applications", but the Python interpreter is not an application in the
usual sense. But it is also not a library in the usual sense, either. So
I'm not sure there IS an obvious right way to support Python on a a Mac.

And I understand the idea behind frameworks, and like them. I've never much
liked the scattering of things all over the filesystem approach that *nix
usually does. But in this case, conda is doing a similar thing, but in a
more powerful and flexible way. So cramming a Framework into conda seems
gratuitous.

As far as I know, the only issue people have had with using a standard Unix
build in conda is the whole GUI thing.Jack mentioned a lot of others,
essentially interacting the the non-kernel part of the OS, but I haven't
heard complaints about that -- maybe because no one's doing that with conda.

But the key technical question I'm still not totally clear on is:

I understand (vaguely) what having Python running from a App bundle
provides -- and these are important features, so we do want to support that.

And I I thought that the executable re-directs to one in a bundle could be
done independently of the Framework, and the fact that the two is
essentially and accident of how they build scripts were set up (and
probably easier to do). If I'm correct, then Python could be built to
provide an app bundle, but otherwise be just like a "normal" unix build.

But what does having Python built as a Framework actually provide, other
than making more like the usual Mac setup? As far as I can tell, it would
provide no new functionality. In which case, given a choice, for, e.g. a
conda build, I'd rather have it be more like the other *nixes than more
like other Mac software.

In short: as far as I can tell, the only reason to use a Framework build in
conda is that it's the only configuration that's already set up to make
pythonw in the build scripts, and autoconf is enough of a pain that one
wants to make a new configuration.

By the way, I chatted with Ned Diely a few years ago about this, and I
think he was thinking of moving away form Frameworks for python.org builds,
though I don't know if he decided not to make that change, or simply hasn't
gotten around to it.

-CHB

References to Discussions:

https://github.com/conda-forge/python-feedstock/issues/23





> Jack
>
> On  14-Mar-2020, at 14:54 , Ronald Oussoren 
> wrote:
>
>
>
> On 13 Mar 2020, at 20:36, Christopher Barker  wrote:
>
> There is a private API that makes it possible to use GUI libraries outside
>> of an app bundle and that’s used by a number of projects, but I wouldn’t
>> want to use that in Python.
>>
>
>

Re: [Pythonmac-SIG] Building plans .....

[Christopher Barker]

>
> There is a private API that makes it possible to use GUI libraries outside
> of an app bundle and that’s used by a number of projects, but I wouldn’t
> want to use that in Python.
>

Is that what TK is doing?

And while probably not good to build it into Python itself, what about
building into the GUI toolkits?

Do you have a reference to that API?

-CHB


Ronald
> —
>
> Twitter: @ronaldoussoren
> Blog: https://blog.ronaldoussoren.net/
>
>
> --
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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] Building plans .....

[Christopher Barker]

On Wed, Mar 11, 2020 at 11:48 PM Just van Rossum 
wrote:

> FWIW, as far as I can tell, a non-framework-build can't be used to build a
> native macos app, at least not with py2app.
>

I'm pretty sure it can. We've moved to PyInstaller, which does work, and
I'm'pretty sure that py2app can work with conda's non-Framework build.

and it's on conda-forge, so presumably it's worked for at least one person
:-)

https://anaconda.org/conda-forge/py2app

I do recall some issues a while back that have presumably been resolved.


> I ran into this while trying to build an app on github-actions, and had to
> resort to downloading and installing Python from python.org upon build.
> Which is wasteful, and in my eyes completely unnecessary.
>
> https://github.com/actions/setup-python/issues/58
>
> I'm sad to learn conda does the same as it renders its Python completely
> useless for my work.
>

Actually, perhaps conda would work for you :-) I'm not clear on what gitHub
actions allows, but you can certainly use conda on, e.g. TravisCI with
OS-X. I've only used it to run tests, but I can't see why you couldn't
build a app that way.

By the way, it's great to "see" all you from back in the day -- this has
been a very quiet list lately!

-CHB


-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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] Building plans .....

[Christopher Barker]

is trivial to have side by side installs of a number of Python
versions, and makes it easy to remove one of them (although that’s less of
a concern from Conda because the tool manages installation and
deinstallation for the user).

Exactly, the entire point of conda is to manage all that for you. And it
manages the entire environment, Python, other libs, even R and Noide if you
want. I used to use the Python Framework, and the OSGEO Frameworks that
Kyng Chaos put together (https://www.kyngchaos.com/software/frameworks/),
and assorted stuff from macport, then brew  Trust me, conda makes this
MUCH easier. And particulary easier to have multipel versions of things
installed.

> It should be easy enough to use the pythonw “hack” from the
Python.framework with a Unix install, the hard part is tweaking the build
process (in particular the Makefile).

Good to know, that's what I suspected. That still seems like the way to go,
unless we can get the GUI toolkits to not require this anymore ...

> BTW. I’d prefer to not add yet another build configuration on macOS,
having both Unix and Framework installs is confusing enough.

well, ideally, maybe we could jetison a few of the older options!

> If the pythonw “hack” is considered useful for Unix installs it should be
enabled unconditionally in 3.9.

I agree. That's kinda the point.

> BTW. Looking further toward the future I’d love to spent time on creating
a “Python.app” that replaces the current framework installers, with some
effort that could remove the need to run installers at all and might even
make it possible to distribute Python through the macOS App Store.

That might be nice -- I htink you have two user groups:
1) Folks that need a quick, easy way to install Python to run with an IDE,
or ...
2) Folks that want to build themselves (or really, to build as part of
another distrobution system: conda, macports, brew, what have you

But what would a Python.App actually be? The fact is that Python is not an
application in the usual sense. It really is a command line system tool and
libraries, and ... It should be installed that way. If that can be done by
the app store, great.

>> The problem is that I *really* don't have the autoconf skills to do that!

>
> But I'm hoping with some prodding and show of support, someone with take
> it on :-)
>
>
> I won’t, finding time to work on Python is hard enough and I’d rather not
> spent that time on fighting the build system ;-).
>

I understand, not sure anyone like to fight with build systems :-(

Thanks,

-CHB

-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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 plans .....

[Christopher Barker]

All,

(mostly Ned and Ronald...)

TL:DR:

Are there any plans to update the build scripts for the python.org
python(s)? It would be really nice to get the mac builds more inline with
the rest of the Unix world.

Longer version:

Over on Conda-forge, we've been struggling with the whole Python.app Bundle
thing:

https://github.com/conda-forge/python.app-feedstock/issues/8

which resulted in:

https://github.com/conda-forge/python.app-feedstock/pulls

Which looks like it's going to solve the "problem at hand".

(NOTE: what that PR does is put a symlink in the app bundle to the main
executable. So pythonw is a bash script that redirects to the symlink in a
bundle which is linked to the regular python executable. I'm amazed that it
works, but it seems to)


But really, it seem that it would be better if in the conda world we "did
this right", which is to say build a python binary that re-directs to a
version inside a bundle to make the OS happy, like is done with the
python.org Framework builds.

There are a number of issues and discussion out there, semi-summaries here:

https://github.com/conda-forge/python-feedstock/issues/23

But a summary is:

The Mac requires that a GUI app executable be "inside" nd application
bundle to access the GUI. This means that a regular old python interpreter
can not be used to run a GUI app (Tk, wxPython, QT, etc.).

This was "solved" many years ago in the python.org "Framework" builds of
Python, by writing a small wrapper around the pythonexe that re-directs
itself to one inside an app bundle. This acts just like a regular command
line executalbe, and thus "python" and "pythonw" can be links to the same
thing.

However, when Anaconda (and now conda-forge) started, they did not use a
Framework build, preferring to keep python more standardized and *nix-y. So
they solved the problem by making a "pythonw" command that is a bash script
that re-directs itself to a copy of the python executable inside an
application bundle. This is delivered as a "python.app" package via conda.

However: while this hack works fine from the command line, it does not work
with setuptools entry points, and other ways of running the app. This has
been a thorn in the side of the (admittedly small) group of folks using
both conda and developing OS-X Desktop apps. And the setuptools folks seem
to have no interest whatsoever in updating setuptools to accommodate
pythonw.

So what I"d like to see happen is for conda-forge to build its python on
OS-X with the little wrapper so that it can be used in place of this whole
python.app hack. I think there are not technical reasons that can't be
done. But the current configure scripts for python.org don't provide that
option, and there has been no one with both an interest in this, the
autotools skills, and the time to make it happen.

I just looked again at the building instructions for the Pyhton.org builds,
and they seem to be pretty old. The Mac has moved on and it seems it would
b good to updated those build options anyway: Do we need 32 bit anymore? Do
we need Universal builds anymore? Should we abandon the Framework build
option altogether?

My proposal: Add a build option that builds Intel, 64bit, fairly recent
SDK, and the pythonw hack, into an otherwise "standard" unix-like build.

Then that could become the default OS-X build in the future, exactly when
TBD.

The problem is that I *really* don't have the autoconf skills to do that!

But I'm hoping with some prodding and show of support, someone with take it
on :-)

-CHB




























-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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] Python bindings for Metal?

[Christopher Barker]

On Thu, Jun 7, 2018 at 6:33 AM, Ronald Oussoren 
wrote:

> Hi,
>
> Does anyone know of Python bindings to Apple’s Metal, and related,
> framework(s)?


no, but I'd ask on the scipy or numpy lists -- someone there would know.



>   I’m particularly interested in the compute parts (basically in the Metal
> equivalent of OpenCL).
>

I wonder if it's that different than OpenCL -- or an Apple rebranding
thing

-CHB



> I’ve search around a bit on PyPI and using Google, but haven’t found
> anything yet.
>
> Ronald
>
> P.S. I’m interested in experimenting with Metal, but at this time not
> enough so to spend a lot of time in first creating bindings.
> ___
> 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, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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] Problem with pip

[Christopher Barker]

This would be a very good time to go over to Python-dev and see what’s
being done for 3.7.

And to help Ned if you want to see changes.

-CHB

On Thu, Jan 18, 2018 at 10:19 AM Joni Orponen <j.orpo...@4teamwork.ch>
wrote:

> On Thu, Jan 18, 2018 at 5:05 PM, Karsten Wolf via Pythonmac-SIG <
> pythonmac-sig@python.org> wrote:
>
>>
>> > On 18.01.2018, at 14:58, Joni Orponen <j.orpo...@4teamwork.ch> wrote:
>> >
>> > The offical CPython distributions seem to be compiled on 10.6 for
>> compatibility reasons. It is easier to compile CPython forwards-compatible
>> than to manually patch pyconfig.h after configure to exclude the syscalls
>> not available on your older target platforms.
>>
>> With the following config line you compile a backwards compatible Python
>> (here 64-bit only since I don't like fiddling around with hard to compile
>> fat-libs).
>>
>> # for 2.7
>> env MACOSX_DEPLOYMENT_TARGET=10.6 CFLAGS="-arch x86_64 " LDFLAGS="-arch
>> x86_64 " ./configure --enable-framework --enable-ipv6 --enable-toolbox-glue
>>
>> and it yields a Python that can be py2apped and run on 10.6 as long as
>> you don't use newer Frameworks or libs that need OSX > 1.6
>>
>
> I'm not sharing your experience.
>
> Adding -Wl,-no_weak_imports to LDFLAGS flags things up and those then
> actually fail hard at runtime. The easiest one to spot and verify yourself
> is getentropy() when using TLS. I'm having to patch out the detected
> support for those syscalls manually out of the generated pyconfig.h when
> compiling something backwards-compatibly for distribution.
>
> I'm also passing through -mmacosx-version-min in both LDFLAGS and CFLAGS
> as not all egg specific build systems pass in the environment correctly,
> but there is still some hope of them to use whatever it is that Python was
> built with as Python exposes that at runtime. There are eggs one still has
> to patch up manually for distribution. This is also useful to be in the
> know of for some of the dependencies of any CPython modules you might have
> to bundle as static libraries for distribution purposes.
>
> For the framework incompatibilities you can get to about the same
> detection ability if you use -Wunguarded-availability in CFLAGS. There is
> also -Wno-unguarded-availability-new which combines to provide the ability
> for not yet caring of non-fatal issues for the newest one (as in the one
> you are currently building on with the intention of being
> backwards-compatible only), but this is rather new [1].
>
> I do not recommend -Werror and -Wunguarded-availability together when
> compiling backwards-compatible as you'd have to fix the use of all the
> deprecated, but not yet broken, bits in CPython itself.
>
> So for targeting 10.6 I'd use something roughly like (also allowing you to
> switch between Xcode versions via xcode-select, if needed):
>
> CC="xcrun cc"
> CXX="$CC"
>
> MACOSX_DEPLOYMENT_TARGET="10.6"
>
> XCODE_ROOT="$(xcode-select --print-path)"
> SYSROOT="$XCODE_ROOT/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk"
>
> COMMON_FLAGS="--sysroot=$SYSROOT
> -mmacosx-version-min=$MACOSX_DEPLOYMENT_TARGET"
>
> CFLAGS="-I$SYSROOT/usr/include $COMMON_FLAGS
> -Wno-unguarded-availability-new -Wunguarded-availability"
> CPPFLAGS="$CFLAGS"
>
> LDFLAGS="-L$SYSROOT/usr/lib $COMMON_FLAGS -Wl,-no_weak_imports"
>
> In practice I'd not target such an old OS version when building
> backwards-compatibly as the associated workload would be rather large.
> Building on the latest version and supporting a couple of versions back
> down is still rather manageable and sane in my experience.
>
> Against this backdrop, I'm understanding of people, especially open source
> volunteers, choosing to build both CPython and their distributable wheels
> on 10.6 as the amount of effort to validate and support more permutations
> is rather large for almost no benefit.
>
> The expectation levels on the Windows side have risen and thus since
> Python 3.5 that stack has moved to build with a newer Visual Studio and is
> also offering a nicer userspace install. I'm taking this thread as a signal
> of the expectations of the macOS crowd having risen as well.
>
> A midway compromise point might be to coerce the community to start
> building on 10.11 as 10.12 was again a great hardware support divider such
> as 10.7 was and it's starting to have been long enough since 10.11.
>
> On the actual topic: If one explicitly needs some build-time details to be
> specific, one can just build the egg oneself. Otherwise whatever pip pulls

Re: [Pythonmac-SIG] PyObjC - Apple sample code

[Christopher Barker]

And you really don't want to use easy_install amymore, either. Try pip.

I see the appeal of an Apple-supplied python, but Apple has never properly
supported it ever since OS-X 10.1.

-CHB




On Fri, Apr 28, 2017 at 5:19 PM Glyph <gl...@twistedmatrix.com> wrote:

> Relying on the system Python for this sort of stuff has always guaranteed
> you'd have an out-of-date version of all of your dependencies.
>
> The availability of wheels (thanks again Ronald!!!) for pyobjc means that
> you don't need the biggest impediment to users installing stuff, which is a
> C compiler.  If you're building stuff for distribution to non-technical
> folks, build it with your own version of python (3) and ship it with
> py2app, not by copying scripts around.
>
> If there are things that make this more painful than just copying
> individual scripts, it's probably best to figure out how to get those
> addressed with the PyPA community.
>
> -glyph
>
> > On Apr 28, 2017, at 4:20 AM, Ben Byram-Wigfield <ben...@me.com> wrote:
> >
> > I ran the installer package for the latest python 2.7, and then used
> easy_install to install PyObjC.
> > I get the same errors on two separate Macs. What should I do to fix the
> installation?
> >
> > Does Apple not have plans to include (all of) the latest PyObjC? That’s
> rather sad. The reason I was attracted to creating ObjC python scripts was
> that they could run on any Mac.
> >
> > Thanks
> >
> > Ben
> >
> >
> >> On 28 Apr 2017, at 08:07, Ronald Oussoren <ronaldousso...@mac.com>
> wrote:
> >>
> >>
> >>> On 27 Apr 2017, at 10:17, Ben Byram-Wigfield <ben...@me.com> wrote:
> >>>
> >>> I tried the repository browser there, and the version of
> parse_page_contents.py still doesn’t work for me. I’m using the latest
> downloaded versions of python 2.7 and PyObjC. I also tried using the
> default OS X versions.
> >>> The errors are in the attached file.
> >>>
> >> The PyObjC 3.2 error at the top of the file seems to indicate that your
> Python installation is broken, PyObjC imports the stdlib io module and that
> causes and error.
> >>
> >> The PyObjC 2.5 error is due to general brokeness of the system
> installation of PyObjC. PyObjC 2.5 is ancient and not something I support
> anymore, furthermore (IIRC) Apple doesn’t ship all of PyObjC. The error
> you’re getting indicates that the framework wrappers are incomplete.
> >>
> >> BTW. If you are new to Python I’d look into using Python 3.6 instead,
> both because that has less change to run into problems due to interference
> between the system install of Python 2.7 and a manual installation, and
> because the Python community is moving ever faster to Python 3.
> >>
> >> Ronald
> >>
> >
> > ___
> > 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 maillist  -  Pythonmac-SIG@python.org
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
>
-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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] PyObjC and macOS 10.12 (Sierra)

[Christopher Barker]

Sorry -- looks like I took this offline by accident.

I really prefer mailing list to be set with reply-to to the list

So I"ll leave more the the thread than I usually do. If your mail client
collapses old quotes, you may want to expand them...

On Thu, Dec 15, 2016 at 9:27 AM, Ronald Oussoren <ronaldousso...@mac.com>
wrote:

>
> On 15 Dec 2016, at 17:34, Christopher Barker <python...@gmail.com> wrote:
>
>
> On Thu, Dec 15, 2016 at 12:59 AM Ronald Oussoren <ronaldousso...@mac.com>
> wrote:
>
>>
>> > Frameworks have the nice feature that everything related to the
>> framework is stored in a single location, with proscribed location for that
>> location.
>>
>> Yeah, I really like the approach -- the *nix habit of scattering stuff
>> all over the place is really ugly.
>>
>> > This is especially useful when doing side-by-side installation of
>> Python 2 and Python 3, those naturally get different locations for their
>> binaries which avoids conflicts when installing scripts into both of them.
>>
>>
>> In the conda case -- conda is managing the whole environment for you
>> instead -- kinda like a monster Framework, I suppose,
>>
>> Putting a Framework inside a Conda environment is kinda weird-- and I
>> think the conda folks wanted to keep things as consistent across platforms
>> as possible.
>>
>
> How does conda deal with having both Python2 and Python3? Or is that out
> of scope?  From what I’ve seen and heard at conferences the scientific
> users of python seem to move to Python 3 at a high speed.
>
>
conda controls python itself in isolated environments, so a given
environment can be python 2 or python 3. and you can have any number of
environments hanging around. It doesn't support python2 and pyton3 is the
same environment though -- which is a pity.


>
>> > Building python.app + the launcher script outside of a framework should
>> be easy, but I don’t understand why you’d want to do so as this will give
>> you yet another way to deploy python on macOS.
>>
>> There are already multiple ways to deploy python on macOS ;-)
>>
>
> I know, but that’s no reason to make it worse.
>

FAir enough -- but having an easy way to build a non-framework python that
supports GUIs would be nice -- and then all teh "unixey" builds could use
that -- so no net increase ;-)



> And in Conda's case, there are good reasons for it. But having the python
> binary in conda work for GUI apps would be a very good thing.
>
> I have never gotten an answer from the conda folks as to why they did the
> app bundle the way they did -- I suspect it was simply the first way they
> came up with that seemed to work.
>
> And apparently there are only a few people trying to use conda for GUI
> apps on the Mac -- no not much motivation for change. ( and what they have
> mostly works)
>
>
> > BTW. In the longer run I’d love to see a binary distribution that’s just
> a Python.app with everything bundled inside, that would reduce the friction
> of installing python even further.
>
> > Installing Python isn't where the real friction is -- it's installing
> third party packages that provides the friction.
>
> A GUI wrapper around pip et al might be a nice thing, though -- so folks
> could have a Mac-ish way to deal with dependencies.
>
> > The main launcher of the app bundle could be a launcher for IDLE,
> possibly enhanced with a menu for installing symlinks to bundled
> executables/scripts into /usr/local/bin.
>
> I don't think that's a good idea -- IDLE has pretty limited usefulness.
> I'd rather see Python installed on such a way as to enable smooth command
> line usage, other IDEs, etc.
>

That shouldn’t be a problem, it would basically switch the current setup
> around: we now have a Python.framework containing a Python.app, and would
> end up with a Python.app containing a Python.framework (or a shared library
> install, doesn’t really matter).  Other tools could still use the python
> installation inside the app bundle.
>

I guess a few well-placed symlinks would make is all work fine.


I mentioned IDLE because that is the primary GUI shipped with the CPython
> distribution and a GUI that’s there is better than one that isn’t ;-).
>

well, yes and no -- I'd rather folks would need to choose an IDE -- an easy
way to choose IDLE would be good, though.


> Which burying it an app might be fine for -- much like the framework
> build. But the "Python" app could be a GUI tool for managing the python
> install -- the symlink thing, package management, etc. maybe a front end
> for py2app? an easy way to bring up a (iPython?) console….
>

If only I 

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

[Christopher Barker]

On Wed, Dec 14, 2016 at 5:32 PM, Glyph Lefkowitz <gl...@twistedmatrix.com>
wrote:

>
> On Dec 14, 2016, at 9:44 AM, Chris Barker <chris.bar...@noaa.gov> wrote:
>
> conda also has a non-framework build of Python -- not sure if that would
> cause any issues with the wheels.
>
>
> I am not up on all the technical specifics, but this suggests to me that
> Conda would be generally unsuitable for use as a Mac native development
> environment, and hence not a Python you'd want to use pyobjc with.
>
> If you don't have a framework build, you don't have an app bundle;
>

in the standard python.org builds, the Framework Build provides an app
bundle. But having python in a Framework is completely orthogonal to the
App BUndle issue.

Yes, you need the executable to be in an app bundle in order to access the
Window manager (and who knows what else), but again, that has nothign to do
with the Framework Build.

unfortunately, the build scripts only have a couple ready-to-go options, so
to get the app bundle executable, you do need the Framework build.

I was talking to Ned Deily about this at pyCon, and I"m pretty sure there's
no good reason for a Framework build at all -- it just seemed like the
Apple-y way to do it at the time, and now we have the legacy.


However, conda has supplied an app bundle version, which you can install
with:

conda install python.app

it supplies a "pythonw" script that bootstraps s python inside a app bundle
and can run GUI apps -- I know it works fine with wxPython, for instance.

Having to use pythonw is a kind of a pain -- and the ned for it was removed
years ago in the Framework builds -- those builds leverage a small
executable that bootstraps into an app bundle -- and works fine as a
"regular" python interpreter as well.

There's no reason we couldn't build that same executable outside a
framework -- someone just need to figure out the build scripts -- which i
was hoping to do last PyCon, but you can only get so much done in a 1-1/2
days of sprinting -- plus I'm no build script expert. At All.


Anyway, it should be easy to see how well the new wheels work with conda --
and/or make a conda recipe -- maybe I'll get to it soon.

-CHB

-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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)

[Christopher Barker]

Personally, I have avoided all this mess the last couple years by using
conda (miniconda install). It does a nice job of keeping entirely separate
from the system ( or any other) python, and it can manage non-python libs
as well, so you don't need Brew. And it has environments that are like
virtualenv, but with the C libs isolated as well.

Between the default channel, conda-forge, and pip for pure python packages,
there is a lot available.

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

- CHB





> >> prediction about setuptools' behavior :)
>
> >
>
> > This seems to be Apple's doing.  AFAICT, 10.12 is shipping with this
>
> > Extras.pth file in /Library/Python/2.7; it's something new.  And,
>
> > unfortunately, due to https://bugs.python.org/issue4865, the
>
> > site-packages directory for the system Python 2.7 is included in
>
> > sys.path along with the non-system framework Python site-packages.
>
> 
>
> >>> So, a little more data:
>
> >>>
>
> >>> If you rename or remove /Library/Python/2.7/site-packages/Extras.pth
>
> >>> then pip2 works.
>
> >>
>
> >> What do you mean by "works"?  Your original error is pip refusing to
>
> >> upgrade pyObjC because to upgrade pyObjC it has to delete the old
>
> >> version, and pyObjC is part of the operating system, and it can't delete
>
> >> the installed version.  This is correct; the error reporting could be
>
> >> nicer, but pip is not broken.  Don't mess with files in /System.
>
> >>
>
> >> The suggestion to use virtualenv isn't really optional.  If you really,
>
> >> really want things to be importable by a bare 'python', not inside a
>
> >> venv, `pip install --user` is another option you might have.
>
> >>
>
> >>> *However*, lots of other stuff breaks -- anything that uses Apple's
>
> >>> python and relies on access to pyobjc and the frameworks (e.g.,
>
> >>> TextMate's latex package).
>
> >>
>
> >> Yep, that's expected behavior.  This is exactly why Apple is making it
>
> >> increasingly difficult to screw up /System.  Apps can, should, and do
>
> >> rely upon the libraries installed on the system.
>
> >>
>
> >>> What I don't understand is: what changed from Yosemite? This file did
>
> >>> not exist before Sierra, but there were no problems with (Apple)
>
> >>> python accessing these packages.
>
> >>
>
> >> Do you mean from El Capitan?
>
> >
>
> > Yes, sorry.
>
> >
>
> >> This file previously existed in a different location, and (while the
>
> >> particulars stubbornly refuse to stick to memory for me, for some
>
> >> reason) this new location is the one generally preferred by the python
>
> >> packaging maintainers.
>
> >>
>
> >>> (Or is there something unique in my setup that is causing this? I kind
>
> >>> of doubt it, but it's possible...)
>
> >>>
>
> >>> Does anyone have any insight?
>
> >>
>
> >> If you really, really, really want to do this in such a way that /System
>
> >> stuff is only present for /System's python and not for python.org
>
> >> 's, you can take advantage of the 'import' hack
>
> >> , and
>
> >> rewrite /Library/Python/2.7/site-packages/Extras.pth to _conditionally_
>
> >> add those entries to sys.path, checking sys.executable or some other
>
> >> fingerprint.
>
> >>
>
> >> But: don't.  Given that system python and python.org  >
>
> >> python share /Library and ~/Library, they're not /really/ distinct
>
> >> environments, and things installed into one will show up in the other,
>
> >> so excluding the /System directories on one but not the other will just
>
> >> cause other, more confusing issues.
>
> >>
>
> >> In conclusion: just use virtualenv.  This is not a problem that should
>
> >> be fixed.
>
> >
>
> > I agree that this would solve all of the problems, at the cost of some
> minor startup pain.
>
> >
>
> > But one nice thing about the python.org builds is that, for the last
> few releases, they just worked out of the box, where by "worked" I mean
> that (as far as I can tell) the system Python saw its own packages, and the
> python.org build saw its own packages, and (python.org) pip didn't seem
> to care about the system files.
>
>
>
> Trust me, they didn't just work :).  There were numerous potential
> misconfigurations that dealt with conflicts between system python packages
> and user-installed packages.  Installing stuff into the global environment
> has always been a bad idea.  Some system files would be on the path, some
> wouldn't, and things installed into one environment would bleed over into
> the other.
>
>
>
> > And I suppose I still don't understand exactly why that changed with
> Sierra, and whether the change is actually beneficial in any way whatever!
> (And whether it could only be fixed by Apple, or whether a change in the
> 

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

[Christopher Barker]

The configure script should come with the source. It is specific to that
particular package, not a system script.

But brew should do that for you anyway.

I have no idea what Appium is, but it looks like it depends on Python --
you probably neeed to install the brew version of Python first.

I would have thought that brew's dependency management would handle that,
but it's worth a try to do it by hand.

-CHB

On Tue, Dec 13, 2016 at 2:28 AM Manohar K Chintala 
wrote:

> Hello Team,
>
> I am setting up Appium for mobile test automation on new Mac with OS X
> 10.11.6 and as part of that I had to run following command.
>
> brew install --HEAD libimobiledevice
>
> 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
>
>
___
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] OS X 10.7 Lion, py2app 0.6.3, argv-emulation, wxPython

[Christopher Barker]

On 8/2/11 6:46 AM, Florian Höch wrote:

Thanks, good to know. Even though personally I don't need 64-bit support
yet, as wxPython currently only works in 32-bit mode on the Mac,


wxPython2.9 (still unstable) is built on Cocoa, and support 64 bit.

http://www.wxpython.org/download.php#unstable

So it's coming soon, and the more people that test it now, the better.

-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 for Tiger PPC I found your wonderful page at http://pythonmac.org/packages/py25-fat/index.html that has numpy and PIL for Tiger, which I can't find anywhere else, but I'm

[Christopher Barker]

Jim Syler wrote:
I found a wonderful page 
at http://pythonmac.org/packages/py25-fat/index.html that has numpy 
and PIL for Tiger, which I can't find anywhere else,


As you've notices, that repository hasn't been maintained for years -- 
to bad.


However, one reason it hasn't is that many package maintainers are 
providing binaries for OS-X themselves. You should be able to get numpy 
from the numpy site.


As for PIL -- various folks have made OS-X binaries, and despite 
expressed interest, somehow they have never gotten put up on the PIL site.


Most recently Russel Owen (on this list) has built PIL binaries and 
posted them on a site of his -- it's not a very public site, but some 
googling (or searching this and/or the PIL list) should find 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] python characters on a mac?

[Christopher Barker]

Karsten Wolf wrote:
Try this. Assuming your text file was encoded in UTF-8. Read the docs 
about unicode and encoding.


exactly. Read this:

http://www.joelonsoftware.com/articles/Unicode.html

and then this:

http://boodebr.org/main/python/all-about-python-and-unicode


-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: unknown required load command 0x800000022

[Christopher Barker]

Donovan Parks wrote:

I'm using py2app 0.6.3 with python2.6, PyQt4, numpy, etc. obtained via
macports.


The entire design of macports is based on users building what they need 
on the machine it is running on.


As a result, it does NOT make it easy to build stuff that will run on 
other machines, particularly older versions of the OS.


You may be able to get it all to work, but I suspect it will be a bit 
fragile as ports are updated.


So I'd either:

Build everything on the oldest OS you want to support.

or

Keep away from MacPorts for stuff you want to py2app (I'm surprized it 
works all, actually! ) The python.org builds are easy to use, install, 
and what py2app is mostly targeting and most tested with. Im not sure 
of the state of binaries for pyQT, but they have certainliy existed in 
the past, and numpy is no problem.



-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

[Christopher Barker]

Mike wrote:

Hi,

I'm using the built in Python 2.6 that comes with OSX. Should I install 
Python from python.org? If so, which version?


That depends on your goals.

If you are happy with your app only running on 10.6 and above, then the 
built-in one should work.


If you want your app to run on OS-X versions 10.3.9 and above (or any 
version before 10.6) then you need to install a python.org version.


You can use either 2.6 or 2.7, but if you use 2.7, use the 32 bit, 
10.3 build -- the 32-64 bit 10.6 build will only run on 10.6


You may want to give that a try anyway, to see if it fixes your issue, 
but Ronald can't fix bugs or add tests if non one gives him broken 
examples -- so if you do want the build-in python, it would be great to 
keep trying an reporting what you find.


One other note -- wx installs itself outside of the Python Framework -- 
this way both the Apple and Python.org installs can use it. It uses some 
*.pth trickery to accomplish that -- that may be what's confusing py2app.


-Chris




Mike
- Original Message - From: Chris Barker chris.bar...@noaa.gov
To: Mike smartmi...@gmail.com; pythonmac-sig@python.org
Sent: Wednesday, June 08, 2011 1:12 AM
Subject: Re: [Pythonmac-SIG] Getting an Error When Running App built 
with Py2app




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 





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

[Christopher Barker]

Chris,

I think your note didn't get posted to the list (you have to reply 
all), so here it is:


Chris Weisiger wrote:
On Tue, Jun 7, 2011 at 10:12 PM, Chris Barker chris.bar...@noaa.gov 
which python are you using? Py2app is really expected to work right

with Apple's built-in python (it can't include python itself)




That should be is really *NOT* expected to work right :)


oops, yes, that is what I meant!

-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

[Christopher Barker]

Ronald Oussoren wrote:

That should be is really *NOT* expected to work right :)



And that's wrong. Py2app should work just fine with Apple's python,
and then creates a semi-standalone app bundle that doesn't include
Python itself. The advantage is a smaller application bundle, the
disadvantage is that you must run it on the same OSX release as you
built it on (or a newer one, AFAIK the result of building on 10.5 can
run on 10.6)


OK -- I've always know that that was supposed to be the case, and a 
py2app'd bundle should certainly work on the machine it was built on anyway.


However, if I recall correctly, there have been issues for years with 
not just the core Python distribution not being included, but things 
getting ugly with installed add on packages not getting included either 
(or not properly). So I've always stayed away from trying, and 
encouraged others to do the same. That experience may be the result of 
bugs that no longer exist.



OTOH, if, indeed, using the system python results in a smaller bundle 
that works just fine on all versions of OS-X = to the one it was built 
on -- that could be really nice and useful.


-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] debugging bus error on launch [py2app]

[Christopher Barker]

Jeffrey O'Neill wrote:
I've used py2app for many years and have really appreciated how it makes 
it so easy to distribute my app.  I'm now running into problems and 
would appreciate suggestions for how to debug. 


You've probably done this, but just to make sure:

Delete the entirety of the build and dist directories and re-run 
py2app -- sometimes left over cruft gets in the way when you change things.


-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] improving interactivity in scripts

[Christopher Barker]

On 5/4/11 2:41 AM, Adam Morris wrote:

I was wondering what sort of options are out there for a poor soul who
deploys Python extensively in his workflows, and uses appscript and
calls to display dialog and the like to interact with the user, but
would really, really like it if there could just be something out
there, as easy as display dialog, that would give me more options for
dialog boxes.

I want something as easy as python to use in my program, and that
doesn't make me use Interface Builder. I don't know why, but I prefer
to handle and maintain everything with straight code.


Do you have any need for something platform independent? wxPython give a 
lot of options, and is particularly nice, I think, if you want to 
describe your dialogs in code. (or maybe it's just NOT nice if you want 
to use a GUI builder...)


It can be a bit verbose to create and use a dialog, but if you have some 
common ones you use, a few utility functions are easy to whip up. It's 
usually used for full-on event driven GUIs, but I've enclosed a sample 
of using dialogs in a procedural, or script-like program.


-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


ProceduralTest.py
Description: application/python
___
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] why does the Mac installer hack the user's .bash_profile?

[Christopher Barker]

On 4/7/11 3:37 PM, Ned Deily wrote:


The Python 2.7.1 installer welcome file, the text that is shown in the
first installer screen, says this:

This package will by default update your shell profile to ensure that
this version of Python is on the search path of your shell. Please
deselect the Shell profile updater package on the package
customization screen if you want to avoid this modification.
Double-click Update Shell Profile at any time to make 2.7.1 the default
Python.

(Earlier installers had slightly different wordings.)

The command that does this is in /Applications/Python m.n/Update Shell
Profile.command.  Normally, it should have saved your .bash_profile as
~/.bash_profile.pysave, but, even if it didn't, the only modification it
makes to your original .bash_profile is to append these (or similar)
lines to the end of the file:

# Setting PATH for Python 2.7
# The original version is saved in .bash_profile.pysave
PATH=/Library/Frameworks/Python.framework/Versions/2.7/bin:${PATH}
export PATH


And a note: before the installer did that, we had a LOT of newbies 
installing python and then having no idea how to get it to run.


I'm a bit confused, Bill. You're just that kind of guy that shouldn't 
have any problem hacking your .bash_profile! i.e. you are not the target 
audience for the installer.


Also: I'm pretty sure it's Apple's fault that a de-installer is not a 
easy and obvious part of a .mpg bundle. I don't think I've ever seen one 
with a uninstaller, as a matter of fact.


-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] Simple PyObjC question: real or vapor?

[Christopher Barker]

just one more note:

On 4/3/11 10:24 PM, Temescal wrote:

  I tried a variation on the PyObjC command:
$easy_install pyobjc
which runs, giving a plethora of errors, and installs various eggs in
/Library/Python/2.6/site-packages,
this despite $which python offers up python 2.7 as the default python.


you need $which easy_install to make sure you are running the right 
easy-install.


It's possible you have not installed setuptools properly (or at all) in 
your python2.7



Don't know anythign about pyObjC, sorry.

wxPython is a pretty good option, though. Probably not as good as pyObjC 
for Mac-only stuff, but it's great for multi platform development, and 
does work quite well on OS-X.


-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] Simple PyObjC question: real or vapor?

[Christopher Barker]

On 4/6/11 1:33 PM, Ronald Oussoren wrote:

I don't agree with your opinion on wxPython, last time I checked it sucked for 
cross platform development because code doesn't always work the same way on 
different platforms (one example I remember from the last time I fought with 
wxWidgets is the background color of text entry fields, changing that on 
Windows is easy enough but the same code doesn't work on OSX).


Well, all that is true, but what that tells me is that cross-platform 
development sucks. wxWidgets does it pretty well, considering.


You could go with QT, and then things will probably work pretty much the 
same on all platforms, but they won't look or act native (particularly 
on the Mac)



I must admit that I haven't worked with the OSX version of wx for a couple of 
years though, because of x-platform issues I switched to running a Windows VM 
whenever I need to write GUI code that might need to run on Windows.


Well, you certainly want to test early and often on all the platforms 
you want to support. In general, if you do things the recommended way, 
it will work on all platforms, but it is pretty easy to do something in 
a way that only works in one place -- in that case, you want to catch 
those things early by testing early.


That's all a bit of a pain, but a LOT easier than writing 3 GUIs.

If you only want to develop Mac apps, Cocoa (via PyObjC) is the way to go.


But at least wxWidgets isn't Tk, the OSX port of Tk seems to get worse over 
time :-(. We've moved from IDLE not looking quite right to IDLE just crashing 
with TkCocoa (for example when using a number of keyboard shortcuts).


yeach.

In fact, the latest wx uses Cocoa (oit had been Carbon). I haven't used 
it yet, but once the bugs get ironed out, it should take us well into 
the future on the Mac.


-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 with py2app 0.6

[Christopher Barker]

On 3/30/11 8:25 AM, Russell Owen wrote:

BTW: I'm also not allowing my code to be zipped up because I use __file__ to 
locate some non-code resources and the dynamically loaded scripts. I should 
convert that code but I'm not sure if there's a standard technique that will 
have long-term support. I recall that the 3rd party setuptools has something, 
but easy_install seems to be in flux.


Indeed setuptools does provide that feature, but frankly, it doesn't 
work well with py2app (or py2exe) packages. You can get it to work but 
only by copying the entire egg into the bundle as-is, and hand-including 
setuptools itself (that may have changed, I haven't tried lately).


In short, your __file__ method is probably easier to deal with, as you 
know exactly what it's doing.


py2app has its own way of dealing with non-code resources, but it's 
really for application specific resources, rather than package-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] py2app and stripped os.environ

[Christopher Barker]

On 3/15/11 6:11 AM, Ronald Oussoren wrote:

Once deployed as .app using py2app, I am not getting all the env vars that are
available to users.



That's on OSX issue, and not a problem in py2app.  Most of the environment 
variables you see from the command-line are initialized by the shell and/or 
Terminal.app and are not available to GUI applications. You'd see the same 
issue with a native application.


Indeed, and we did explain that to the OP on the wxPython list.

However, it seems that it is fairly common that folks write applications 
that call command line utilities. In this case, they need the 
environment to be set up the way that it is in the user's default shell. 
I suggest that it might be nice to have an option for py2app to build an 
app that will initialize the environment that a user would see in their 
standard shell.


Thanks to a suggestion by Robin Dunn, the OP has found a solution, in 
which the start up app is replaced by a shell script that then calls 
exec to start up the actual app -- this assures that the shell is 
initialized, and the environment passed on to the app itself:


#!/bin/bash
DIR=$(dirname $0)
exec $DIR/launch

I don't know if that's a robust way to do it or not. If nothing else, it 
assumes that the user's default shell is bash, which is common, but not 
guaranteed.


so:

1) is there a better way to accomplish this task?

2) if so, does it make sense to built it into py2app as an option?


-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: Re: py2app and stripped os.environ

[Christopher Barker]

Re-posting -- for some reason this didn't seem to show up in the list.

-Chris


 Original Message 
Subject: Re: [Pythonmac-SIG] py2app and stripped os.environ
Date: Tue, 15 Mar 2011 13:09:28 -0400
From: Ronald Oussoren ronaldousso...@mac.com
To: Christopher Barker chris.bar...@noaa.gov
CC: pythonmac-sig@python.org


On 15 Mar, 2011, at 11:57, Christopher Barker wrote:


On 3/15/11 6:11 AM, Ronald Oussoren wrote:

Once deployed as .app using py2app, I am not getting all the env vars that are
available to users.



That's on OSX issue, and not a problem in py2app.  Most of the environment 
variables you see from the command-line are initialized by the shell and/or 
Terminal.app and are not available to GUI applications. You'd see the same 
issue with a native application.


Indeed, and we did explain that to the OP on the wxPython list.


It would have been nice if he'd mentioned that in his post here.



However, it seems that it is fairly common that folks write applications that 
call command line utilities. In this case, they need the environment to be set 
up the way that it is in the user's default shell. I suggest that it might be 
nice to have an option for py2app to build an app that will initialize the 
environment that a user would see in their standard shell.


That is non-trivial, especially when the user has specified a different 
shell in the Terminal preferences.  To get the right environment you'd 
probably have to:


* Reverse engineer the default shell created by Terminal.app
* Parse the environment plist file (I don't recall the name, but have an 
PyObjC example that uses is)
* Run 'login -f USER' in a subprocess, then run the env command using 
that shell


All of this should be done in a bootstrap script (in py2app), and code 
should then be added to the distutils command to ensure that the script 
gets included when an option is specified (lets say, 
--emulate-shell-environment)


All of this is definitely possible, but I don't know when I'll get 
around to doing it.


If someone can write a function that fetches the information I can 
easily integrate it into py2app. This should be a function that takes no 
arguments and updates os.environ, something like:


.. def _emulate_shell_environment():
.. import os
.. os.environ['KEY'] = 'value'

BTW. I've filed issue #15 for this, to ensure the request doesn't get 
lost 
(https://bitbucket.org/ronaldoussoren/py2app/issue/15/py2app-should-have-way-to-emulate-shell)


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] Framework Python and X11

[Christopher Barker]

On 3/10/11 12:22 PM, Ned Deily wrote:

The python.org installers for Mac OS X do not support linking to an X11
tkinter.  The simplest solution might be to install a Python from
MacPorts.


probably so, but



 The current MacPorts Tk is an X11 Tk, its Pythons are
framework builds, and it has its own wxPython ports.


I looked, and the wxPython ports are wxmac, not wxGTK, which I think 
is what the OP wants.


The fact that macports has done it means it can be done, so the OP would 
compile his own python as well. I think he's got it working with TK the 
way they want, so could he just add the framework flag and be done?


-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] Scientific Software developer wanted in Seattle.

[Christopher Barker]

Scientific Software Developer
NOAA Emergency Response Division

Help us develop our next-generation oil spill transport model.

Background:
The Emergency Response Division (ERD) of NOAA's Office of Response and 
Restoration (ORR) provides scientific expertise to support the response 
to oil and chemical spills in the coastal environment. We played a major 
role in the recent Deepwater Horizon oil spill in the Gulf of Mexico. 
In order to fulfill our mission, we develop many of the software tools 
and models required to support a response to hazardous material spills. 
 In the wake of the Deepwater horizon incident, we are embarking on a 
program to develop our next-generation oil spill transport model, taking 
into account lessons learned from years of response and this major incident.


General Characteristics:
The incumbent of this position will provide software development 
services to support the mission of the Emergency Response Division of 
NOAA's Office of Response and Restoration. As part of his/her efforts, 
independent evaluation and application of development techniques, 
algorithms, software architecture, and programming patterns will be 
required.  The incumbent will work with the staff of ERD to provide 
analysis on user needs and software, GUI, and library design. He/she 
will be expect to work primarily on site at NOAA's facility in Seattle.


Knowledge:
The incumbent must be able to apply modern concepts of software 
engineering and design to the development of computational code, desktop 
applications, web applications, and libraries. The incumbent will need 
to be able to design, write, refactor, and implement code for a complex 
desktop and/or web application and computational library.  The incumbent 
will work with a multi-disciplinary team including scientists, users, 
and other developers, utilizing software development practices such as 
usability design, version control, bug and issue tracking, and unit 
testing.  Good communication skills and the knowledge of working as part 
of a team are required.


Direction received:
The incumbent will participate on various research and development 
teams.  While endpoints will be identified through Division management 
and some direct supervision will be provided, the incumbent will be 
responsible for progressively being able to take input from team 
meetings and design objectives and propose strategies for reaching 
endpoints.


Typical duties and responsibilities:
The incumbent will work with the oil and chemical spill modeling team to 
improve and develop new tools and models used in fate and transport 
forecasting.  Different components of the project will be written in 
C++, Python, and Javascript.


Education requirement, minimum:
Bachelor's degree in a technical discipline.

Experience requirement, minimum:
One to five years experience in development of complex software systems 
in one or more full-featured programming languages (C, C++, Java, 
Python, Ruby,  Fortran, etc.)


The team requires experience in the following languages/disciplines. 
Each incumbent will need experience in some subset:


 * Computational/Scientific programming
 * Numerical Analysis/Methods
 * Parallel processing
 * Desktop GUI
 * Web services
 * Web clients: HTML/CSS/Javascript
 * Python
 * wxPython
 * OpenGL
 * C/C++
 * Python--C/C++ integration
 * Software development team leadership


While the incumbent will work on-site at NOAA, directly with the NOAA 
team, this is a contract position with General Dynamics Information 
Technology:


http://www.gdit.com/default.aspx

For more information and to apply, use the GDIT web site:
https://secure.resumeware.net/gdns_rw/gdns_web/job_detail.cfm?key=59436show_cart=0referredId=20

if that long url doesn't work, try:

http://www.resumeware.net/gdns_rw/gdns_web/job_search.cfm

and search for job ID: 179178


NOTE: This is a potion being hired by GDIT to work with NOAA, so any 
questions about salary, benefits, etc, etc should go to GDIT. However, 
feel free to send me questions about our organization, working 
conditions, more detail about the nature of the projects 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] C++ ABI 1002/102 incompatibility with wxPython on OS X

[Christopher Barker]

On 3/1/11 1:34 PM, Brendan Simon (eTRIX) wrote:

An app that works on PowerPC and Intel 10.4.11.

$ cat ./MyApp.app/Contents/Frameworks/libwx_macud-2.8.0.dylib | strings
| grep ABI
2.8 (debug,Unicode,compiler with C++ ABI 102,wx containers,compatible
with 2.6)
2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible
with 2.6)


This is presumably the PPC and Intel parts of the lib.

IIRC, at one point (about two years ago), Robin did some machinations to 
build the PPC version of the binary with a different compiler version 
than the Intel version. I needed to go through the same machinations to 
build an extension that was linked against wxPython.


I think that was required to get a build that would work on 10.3.9 PPC 
and recent Intel machines. Apparently, it's required for 10.4, too. I, 
unfortunately, don't have a 10.4 machine to test on anymore, so it' a 
bit hard for me to help. HOwever, looking at my ugly build script, it 
looks like I'm essentially doing:


1) build a regular old extension
2) using lipo to remove the PPc part
3) setting ENV varibles to use gcc3.3:
# this builds the ppc version correctly
export CXX=g++-3.3 -arch ppc -DMAC_OS_X_VERSION_MAX_ALLOWED=1040
export CC=gcc-3.3 -arch ppc -DMAC_OS_X_VERSION_MAX_ALLOWED=1040
export MACOSX_DEPLOYMENT_TARGET=10.3
4) pull the ppc part out of that build, and add it inot the original one.

when I look at the dylib delivered with that app, I get:

$ cat libwx_macud-2.8.0.dylib | strings | grep ABI
2.8 (debug,Unicode,compiler with C++ ABI 102,wx containers,compatible 
with 2.6)
2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible 
with 2.6)


when I look at the one in /usr/lib, which I presume was supplied by 
apple, I get:


2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible 
with 2.6)
2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible 
with 2.6)


(this is with OS-X 10.6).

When I look at the one in :

/usr/local/lib/wxPython-unicode-2.8.11.0/lib/
(which I got from a wxPython binary), I get:

$ cat libwx_macud-2.8.0.dylib | strings | grep ABI
2.8 (debug,Unicode,compiler with C++ ABI 102,wx containers,compatible 
with 2.6)
2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible 
with 2.6)


Which is what you want.

I suspect that you're now using Apple's wx, by accident, or are you 
using a newer wxPython than 2.8.11 ?



-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++ ABI 1002/102 incompatibility with wxPython on OS X

[Christopher Barker]

On 3/1/11 1:58 PM, Christopher Barker wrote:


When I look at the one in :

/usr/local/lib/wxPython-unicode-2.8.11.0/lib/
(which I got from a wxPython binary), I get:

$ cat libwx_macud-2.8.0.dylib | strings | grep ABI
2.8 (debug,Unicode,compiler with C++ ABI 102,wx containers,compatible
with 2.6)
2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible
with 2.6)


One more note:

I just took a look at an app bundle I recently built with wx -- it has 
the right ABI versions. This is with:


Python 2.6.6 (from Python.org)
wxPython 2.8.11.0 (from wxpython.org)

So it can be done.

-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 with wxpython

[Christopher Barker]

On 2/17/11 2:05 AM, Gerhard Schmidt wrote:

Hi,

i try to generate an app from a wxPython project.

Generation the App runs without an error. But when i try to start the
App it terminates.


versions of python (and which binary install), py2app, wxPython, OS-X ?


The logs show that import wx doesn't work.


can you build a really, really simple wx app? (see enclosed)


What am i missing.


I'm not sure, but you do have something extra:

 CFBundleIdentifier = 
com.acf.vereinsverwaltung,

 )
  ,'packages':  'wx'

you don't need to specify the wx package -- if there is an import wx 
in your code, py2app will find it.



  ,'site_packages': True

And I don't remember what this does -- try taking it out 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


basicwx.py
Description: application/python


setup.py
Description: application/python
___
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 - .app size is too big

[Christopher Barker]

On 2/16/11 8:46 AM, Aahz wrote:

On Wed, Feb 16, 2011, Prashant Saxena wrote:



After installing py2app using python setup.py install, I created an .app of
default wxpython's example name superdoodle.
The resulting superdoodle.app is around 48.5 MB.



wxpython by itself probably accounts for about 10MB.  You should be able
to compress that down to around 15MB if you're distributing an installer
package.


Actually, wxPython is really big, and with the universal build, it's 
twice as big.


On my system (Python 2.6 Universal):

minimal python app  : 9.1MB
minimal wxPython app: 43MB

But the wxPython one does compress down to 17MB

wxPython is so big because it has all of the wx C++ libs, plus all the 
wrapper code to access it. It is unfortunately pretty monolithic, so 
it's very hard to bring in just what you need. But disk space is cheap 
these days.


-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] Mac and Python (absolute begineer)

[Christopher Barker]

On 2/10/11 6:49 AM, Kevin Walzer wrote:

I'm not sure about Cython or Swig, but extensions build with distutils
pick up the settings of your Python installation and should do the right
thing.


They both produce C code, how you compile them is up to you -- they also 
both have confusing directions about that on some sites -- so make sure 
to use ditutils to build -- i.e. write a  setup.py. That's the best 
way to do it on other platfroms 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] Some test code

[Christopher Barker]

On 2/2/11 8:45 PM, Chris Rebert wrote:


Also, your question isn't Mac-specific, so for future reference, it
would have been better posed to the more general and widely-read
python-list (http://mail.python.org/mailman/listinfo/python-list ).


or better yet, the python tutor list:

http://mail.python.org/mailman/listinfo/tutor

-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++ ABI 1002/102 incompatibility with wxPython

[Christopher Barker]

On 1/26/11 7:06 AM, Lou Pecora wrote:


Any idea how to see what ABI version a given binary was compiled against?



I thought otool could do that.  Try,

otool -L ABI

Do a

man otool

to see more.
Let me know if that works.


nope, can't find anything about ABI version in the man pages, and I've 
tried all the switches that looked like they might have something.


You'd think it would, though -- maybe I missed 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
___
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] Determining if I need an import

[Christopher Barker]

On 1/27/11 3:48 AM, Henning Hraban Ramm wrote:

Am 2011-01-24 um 23:52 schrieb Chris Weisiger:



I use Eclipse/Aptana with PyDev, and if you manage to setup that
monster, it shows unused imports (as well as unused variables etc.)
quite nicely.


pychecker is worth a try, too:

http://pychecker.sourceforge.net/

It'll likely find other stuff you want to know about as well.

-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++ ABI 1002/102 incompatibility with wxPython

[Christopher Barker]

On 1/25/11 1:20 AM, Brendan Simon (eTRIX) wrote:

I have a wxPython app that is built with py2app. A user recently
reported the following error when trying to run the app.

Fatal Error: Mismatch between the program and library build versions
detected.
The library used 2.8 (no debug,Unicode,compiler with C++ ABI 1002,wx
containers,compatible with 2.6),
and your program used 2.8 (no debug,Unicode,compiler with C++ ABI
102,wx containers,compatible with 2.6).
Abort trap
logout


That looks odd to me -- as far as I can see (did I miss something?) the 
only difference is ABI 102 vs ABI 1002 -- that almost looks like a typo.


I would ask on the wxPython list -- perhaps Robin will recognize those 
ABI numbers. And Im not sure how to get those numbers at either run 
time or otherwise -- anyone know?


Meanwhile a couple questions/thoughts:

  It appears to be a difference in the wx libraries on the target system

and the wx libraries on the build system.

Unfortunately, at this stage, I do not know what the OS X version is on
the target system.

The app was built using Python 2.5.4, (wxPython 2.8.11.0 or 2.8.4.2 ??)
on OS X 10.6.6.


Is that the apple's python? i.e. the one in:

/System/Library/Frameworks/Python.framework/Versions/2.5

If so, that is likely your problem. py2app does not bundle up everything 
if you're using Apple's python, so your python install and your users 
may be different.



Is there anyway to fix this with a py2app setting ??


not until we figure out what's wrong...


Doesn't py2app copy all the libraries to the app bundle ??


it should, but it won't if you are using Apple's python, and sometimes 
things go wrong. wxPython puts itself in /usr/local/, while putting 
nifty sys.path manipulations in the python installs, so things can get a 
bit confused. But it's done so that one installer can support both 
python,org and apple pythons.


 I guess that
 doesn't guarantee that the libraries will load on any OS.

no, it doesn't, but it should load on any version that your supporting 
libs are built for -- the standard wxPython installers are built for 
10.4 and above (maybe 10.3.9 --not sure about that), and so is the 
python,org python -- are you using any other third-party libs that 
aren't pure python?


debugging suggestions:

 -- use the python.org python if you are not already.

 -- add a print sys.path in your app (before importing wx) -- then 
check the console to see what it prints, both in and out of an .app 
bundle - that should give you a clue -- if you can have your user report 
what they get -- that will be best.


 -- take a look in the generated app bundle -- it's just a directory -- 
you can see what's in there, and it will give you a clue.




What about path settings ??


py2app should take care of that, but looking at sys.path will let you 
know if it's doing it right



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] C++ ABI 1002/102 incompatibility with wxPython

[Christopher Barker]

On 1/25/11 12:19 PM, Matthias Baas wrote:

It's not a typo, the numbers indicate the C++ ABI (Application Binary
Interface) version the code uses.



As far as I know, version 1002 is still the current one and it was
introduced by gcc 3.4. Before that, the version was 102 (don't ask me
how these numbers are formed. I have to admit, it's a bit of an odd
numbering scheme...).


It's that odd numbering scheme that threw me.


You can find out the ABI version a particular version of gcc uses by
running the following command:

g++ -E -dM -/dev/null|grep ABI


Any idea how to see what ABI version a given binary was compiled against?

-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 not including /Library/Python/2.6/site-packages

[Christopher Barker]

On 1/24/11 10:57 PM, michael ferraro wrote:

I should clarify-  My apps are used in intense live animation production 
applications.

Having an app the runs like an app, can be executed from the dock and in all
aspects seems like a real Mac- app, for me, makes it possible to experiment with
new  models of media production. This is  my stock-and-trade.


yep -- it really nice if you use the GUI for other parts of your process.


Adding insult to injury, I am constantly in development. So ... I am never 
ready to commit
(no pun intended). I need to fix things at a crucial moment. I need to add a  
featur
  that no one anticipated.  I can't be rigid and orthodox here

py2app is 99.9 percent exactly what I need.  It it excellent and has been a 
terrific
help to me a and to the the community.  I just got lost and frustrated in the
morass of development.


I use it that way too. I have a few apps that are under constant 
development (some mine, and the Peppy editor). I use Py2app to build an 
Alias bundle, and then I have an app that looks, feels and acts like an 
app, but actually runs the development code and my Python install. I 
can't give it to anyone else, but I can set up others with a similar 
python install and set them up the same way.



Using Apple's installed python means one less install and, one less opportunity
for problem.


I'd think that what you are trying to do should work. And if you can 
figure it out what went wrong, please report here.



It is probably shortsighted.  Given everything, installing a python.org
version of python might make things more consistent and easier.


I think so -- and yes, it's one more install, but it's a pretty darn 
easy 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] Python development on OSX

[Christopher Barker]

On 1/20/11 4:51 PM, Adam Morris wrote:

I want one programming language that lets me solve my real
problems.



That to me, is what Python embodies.


yup -- it is applicable to a VERY wide range of problems.


But I'm still confused on some major points on what it offers.



 I use Xcode and Cocoa-Python, and

IMO it works great.  Is that using py2app under the covers?  This
is another reason not to install a non-system Python; it sometimes
screws up apps built using Xcode and Python.


I'm trying really hard to unpack this. I can't use XCode and the
py-objc bridge with my installed python 2.7 setup? (Installed isn't
quite the right word, I know.) Why not? I guess it's because something
is hard-coded somewhere ...

I don't particularly need XCode but I really want to understand this.


You can certainly use pyObjC without XCode. I've never tried to do 
python development in XCode, from the little I've read here it never 
seemed to be well supported. Maybe someone here can tell you how to use 
XCode / pyObjC for app development.


Note that Apple has added a couple proprietary bits to its python 
install, maybe XCode relies on those.


I would love to hear more about what you can and can't do with XCode.

Note that if XCode has a way to build a self-contained App, and it uses 
Apple's system python, you are going to either get something that won't 
work on older systems, or you are going to be using an older python. You 
can't re-distribute Apple's python.


Also -- Apple has NEVER upgraded a python it delivered. Most of the bugs 
fixed between X.1 and X.5 versions of python are unlikely to bite you, 
but I had at least one that did -- when I found it, it had been fixed in 
the python.org release, but not in Apples -- and Apple has still not 
fixed it -- so I don't know what I'd have done if I'd be confined to 
Apple's python. Yes, I'm confined to Apple's OS - but at least they do 
update that!



And Bill's right -- if you want to support other platforms, wxPython or 
pyQT is the way to go. (pyGTK is so non-native on the Mac I wouldn't 
consider it, and I don't think pyGUI is very mature yet)


(the binaries for wxPython work with both the Apple and python.org 
builds -- 32 bit only for the moment)


-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 development on OSX

[Christopher Barker]

On 1/19/11 9:11 PM, Charles Hartman wrote:

Do I need/want to use py2app to distribute my app(s)?
Never happens.



But this is where Bill J's use-case departs drastically from those of
many users, perhaps most, and certainly the majority of those who need
any help.


I'm not sure about majority -- who knows, really?


Despite what's sometimes implied here, py2app is not a frill.


I agree. It's a really key tool.

One of the great things about Python is that it is suitable for:

Quickie command line scripting

Gluing larger systems together

Full on application development:
 - web apps
 - command line apps
 - GUI apps.

And on the Mac, you can:
 - build native apps with PyObjC
 - build cross-platform GUIs with wx or QT
 - build Unix-y apps with pyGTK
 - drive other apps with AppScript

Essentially ANY kind of development short of device drivers.

Is there ANY other language you can do all that with? (Ruby, maybe?)

So while py2app may not be essential to the Python community on Mac, 
it IS essential to a fair fraction of that community, and I think that 
fact that you can do all these kinds of development with the same tool 
strengthens its position for the other purposes as well.



and certainly the majority of those who need any help.


I think that's key -- Bill's approach is fine one for some users, but 
not what Id recommend to newbies that aren't sure how to set a PATH.


The fact that there are a lot of ways to install Python on the Mac has 
really been a pain for the community to support (and pretty ironic, 
considering how the Mac platform usually is!). I'm not sure there is 
much that can be done about it, but one thing we have mostly done is try 
to use this list to declare the python.org builds as the official ones 
and try to get third party projects to build binaries for them


If you need help with macports, ask on a macports list, 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] Installing modules with py2app

[Christopher Barker]

On 1/20/11 2:10 PM, Mier, Alejandro wrote:

The problem is that, even though subprocess.call(python setup.py install) 
picks up the system python
(sys.executable has the expected value), it still loads the modules from the 
site-packages.zip in the .app bundle.


I suspect that you are getting environment variables set by py2app, 
rather that the user's raw environment.


Maybe it shouldn't be a subprocess -- what happens if you do a simple:

os.system(python setup.py install)

 you also may need to make sure the working dir is correct:

os.system(cd the/full/path/to/setup; python setup.py install)



-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 development on OSX

[Christopher Barker]

NOTE:

I'm not trying to persuade Bill of anything -- he's clearly found a 
method that works well for him, but for future googlers, I think a few 
clarifications are in order:


On 1/18/11 4:29 PM, Bill Janssen wrote:

Bill -- I'm really curious what issues you've had --



In general, there are issues around site-packages, paths, and other such
things.  I don't think you and I necessarily have much trouble with it,
but I tend to help others with Python on Macs, and they seem to get into
all kinds of trouble.  The best one I've found is one group who had
decided to upgrade their Leopard Python to 2.6.  They'd installed the
python.org Python, removed the symlink /usr/bin/python, and re-linked
/usr/bin/python to the 2.6 version.  They were happy, but plagued by odd
problems with their machines that didn't (to them) seem to be
Python-related.


OK -- well, I'd say the solution to that is simple: DON'T DO THAT. We 
say time and time again that you should NEVER mess with Apple's python.


So there problem was not that they installed another python, but that 
they broke Apple's. And there is no need -- they got too smart for their 
own good. The python.org installer changes the users PATH anyway. 
(granted, not for all users, but if you have a multi user system, you'll 
need to know how to manage PATHs anyway -- and /usr/local should be on 
everyone's PATH)



Another problem I've run into more than once was that the user had
installed different incompatible versions of an extension, and couldn't
see why an application (with an embedded Python interpreter) was
misbehaving -- it was getting the wrong version of the extension.


Well, Even Apple supplies more than one version these days -- if you are 
embedding Python, you're going to need to know what you are doing.



Not sure this is much use to anyone, but here's my decision tree, which
has worked well for me over the past 7 years:


1) Do I do a bunch of unix-y command line stuff in general, and not
want to develop OS-X GUIs?


if yes -- use system Python.


well, I meant a bunch of unix-y stuff in addition to Python -- stuff 
that Apple doesn't give you -- I use MacPorts for a bunch of 
command-line scientific tools, and it would make some sense to use 
macports python for those things, too (dependencies and all).


But yes, if you are doing command line stuff and don't need anything 
Apples doesn't give you -- the Apple python is fine (unless you need a 
newer version)



if no:


Do I need/want a newer version than Apple provides?


if yes: build non-framework version from source.


I can hardly see this as easier/more reliable than installing the 
python.org build -- if you build from source and overwrite 
/usr/bin/python, you'll sure get the same problems! And anyone that can 
build from source understand PATHs, etc, enough not to screw things up!



Do I need/want to use py2app to distribute my app(s)?


Never happens.


fair enough.


Do I want to use pre-build binaries of common hard-to-build packages?

if yes: cry about the general unfairness of the world, then build them
from source instead to work with the system Python.


Why cry when wxPython, PIL, SciPy, Matplotlib, ??? are available as 
nifty easy to use installers?


There really aren't very many people for whom build it from source is 
the best option.



Final NOTE: It's great that Bill takes this approach -- he's gotten 
things working and helped others a lot -- someone's got to build from 
source! Thanks, Bill!


-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] Installing modules with py2app

[Christopher Barker]

On 1/18/11 9:05 AM, João Vale wrote:

Do you have distutils installed? It usually doesn't come bundled with
Python.


huh? Sure it does -- distutils has been standard in Python for many many 
years.


So that's not it.

Besides, if you can run it unbundled, you have the packages you need, 
the question is how to get them properly into the py2app 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] Python development on OSX

[Christopher Barker]

On 1/17/11 9:17 AM, Bill Janssen wrote:

And- I want to update the default python that came om my macbook pro to 2.7.
Should I do install that from Python.org?


My advice?  I've never had good luck trying to update the default
Python that comes with the Mac.


Bill -- I'm really curious what issues you've had -- I haven't tried to 
use Apple's Python is many years (OS-X 10.2, I think) -- and it used to 
be painful to do so. Since then I've stuck with the Python.org versions, 
and had no problems (at least none that would have been solved by using 
Apple's Python).


Here's my decision tree:

1) Do I do a bunch of unix-y command line stuff in general, and not want 
to develop OS-X GUIs?


if yes -- use Macports

if no:

Do I need/want a newer version than Apple provides?

if yes: python.org build

Do I need/want to use py2app to distribute my app(s)?

if yes: use the Python.org build

Do I want to use pre-build binaries of common hard-to-build packages?

if yes: use the python.org build.


You can see that most roads lead to the python.org builds.


That being said, to be clear:

You don't upgrade Apple's python. Rather, you install a new one 
alongside it, and use that for your work.



It is safe to build (and run) a non-Framework build of other versions of
Python in various places on your Mac, but life gets complicated if you
attempt to install it.


Again, I've never had a complication from an installed python.org build. 
You sure would if you put it in the same place as Apple's but the 
installers don't do 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] Installing modules with py2app

[Christopher Barker]

On 1/18/11 2:47 PM, Mier, Alejandro wrote:

I modified the included distutils files, and managed to get this stack trace

Traceback (most recent call last):
   File distutils/dist.py, line 837, in get_command_class
 __import__ (module_name)
   File distutils/command/install.py, line 21, inmodule
 from site import USER_BASE
cannot import name USER_BASE

The site.py included in the bundle has this comment: This is stripped down and 
customized for use in py2app applications

So apparently, py2app is removing USER_BASE and USER_SITE from site.py. I am 
not sure why it does that, but it is preventing the installation of modules 
with py2app.

I worked around it by modifying the included site.py to declare USER_BASE and 
USER_SITE after generating the .app bundle.

I think this might be a bug in py2app, but would like to know your input on 
this.


I don't think it's a bug -- you may have some problems with this. I'm 
not sure I quite get what distutils is doing with USER_BASE and 
USER_SITE, but I suspect that they are using them to figure out where to 
install stuff. That should be a function of the python you are 
installing to. A py2app bundle isn't usually installing stuff into itself.


How are you using distutils in this case? Are you installing stuff into 
the app bundle? Or into a system python? If a system python, you should 
probably use the system python's distutils (and thus its site.py) to do 
the work.


If you are installing into the app bundle (cool idea!), then you'll need 
to make sure that USER_BASE and USER_SITE are set correctly at run time 
for where the user happens to have put the py2app 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] Popen and py2app

[Christopher Barker]

Adam Morris wrote:

Could this be a problem with py2app, or is there something about the
run-time environment I've overlooked?

Would also be interested if there is a better way of checking to see
if a command line utility is currently located in the path for the
current user's system.


I think what you've done is correct -- i.e. it's not on the PATH for the 
users system.


For the most part, the PATH for the command line is added to the shell 
rc scripts, so if you are not running from a shell (i.e. from a py2app 
bundle) you won't have the additional entries on PATH (like /usr/local/bin).


I'm pretty sure there is a way to edit a plist somewhere to add to the 
PATH system (or user?) wide. However, if you're delivering an app 
bundle, you probably don't want to require your users to do this.


I may misunderstand your use case, but I think you could specifically 
search for the utility in places it might be expected to be found:


/usr/bin
/usr/local/bin
/sw/... (for fink)
/opt/... (for macports)

rather then expect it to be on the PATH.

-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] 2.7.1 build?

[Christopher Barker]

Hey folks (or should I say Ronald?),

What's up with binary builds for 2.7.1?

Python.or has recently released 2.7.1, but there are no mac binaries yet.

This wouldn't be a big deal -- I'm patient, but unfortunately the way 
the python.org web site is set up, it's easy to find 2.7.1, but next to 
impossible to find 2.7.0 -- they appear to only put in links to the 
latest minor release. I say next to impossible, because I haven't 
found it yet, and I've been poking around the web site for a few minutes.


so, we really need either a set of 2.7.1 builds, or at least a link on 
the python.org site somewhere obvious for the 2.7.0 builds!


-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] 2.7.1 build?

[Christopher Barker]

On 11/29/10 10:15 AM, s...@pobox.com wrote:

Drop the .0 and I think you've got it:

 http://www.python.org/download/releases/2.7/


yup -- thanks Richard and Skip -- thank god for restfull urls!

-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] Amateur question about modules

[Christopher Barker]

On 11/3/10 3:30 PM, Kevin Walzer wrote:

So, how can I correctly import this module?
And where should I put it, so Python can find it.



TkSnack is a Tkinter wrapper for the Snack sound library. You'll need to
install TkSnack in your site-packages path and Snack in a place where
Tkinter can find it like /Library/Tcl. Google can direct you to download
sites.


Chances are, TkSnack will come as an egg which you can easy_install, or 
a with a setup.py that will isntall it to the right place for you:


python setup.py install

Just make sure python runs the python you think it does.

-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] If/else vs or

[Christopher Barker]

On 10/29/10 7:56 AM, Dan Ross wrote:
 I've been trying to use more list comprehensions recently.

ahh -- then you want something like:

In [15]: colors = ['red','green','blue','orange','fuchsia','black','white']

In [16]: subset = ['red','green','blue','purple']

In [17]: [c for c in colors if c in subset]

Out[17]: ['red', 'green', 'blue']


(so much for one obvious way to do 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 on linux

[Christopher Barker]

On 10/28/10 12:04 AM, BjornJohansson wrote:

Apple does not allow you to run their os on non-apple hardware which means
that it is next to impossible to create mac executables without apple
hardware legally?


yes that is true. If you aren't worried about legality, you could run 
OS-X on a hackintosh or in a VM, but you are quite right, that 
violates Apple's license.



This is a pity, because I do not want to force even more
people to Microsoft.


Then send them top Linux...

But if you have a user that want's a Mac version, then they have a Mac, 
so you can hopefully find one that will let you use their machine to 
build binaries.


-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 on linux

[Christopher Barker]

On 10/15/10 7:57 AM, Ronald Oussoren wrote:

It is in theory possible to tweak py2app to do this, all of py2app is
python code and py2app doesn't use the C compiler.


Doesn't py2app need to use macholib to edit shared libs it's bundling? 
Is that pure python, and not dependent on any OS-X specific libs?



BTW. While it is possible to tweak py2app to do its work on a Linux box
I'm not interested in doing the work.


Frankly, I don't see it as worth the effort.

-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 on linux

[Christopher Barker]

On 10/15/10 6:49 AM, Daniel O'Donovan wrote:

But Freeze may be of interest to you : http://wiki.python.org/moin/Freeze or 
even PyInstaller http://www.pyinstaller.org (though I don't use either)...


or bbFreeze.

-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] swig example on mac osx 10.6.4

[Christopher Barker]

 in example_wrap.o
 _swig_varlink_type in example_wrap.o
ld: symbol(s) not found for inferred architecture x86_64




___
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] bdist_mpkg issues

[Christopher Barker]

Russell E. Owen wrote:
At your suggestion I built new universal unix libraries using 
MACOSX_DEPLOYMENT_TARGET=10.3. As always, I deleted the dylibs so only 
the static libraries remained (so they would be included in the final 
binary) and I verified that the libraries contained both ppc and intel 
code. I then used bdist_mpkg to build a matplotlib installer. 
Unfortunately I see the same problem as before: when I try to import 
pylab on a 10.3.9 PPC computer I get a segfault.


Darn.

Is there any simple test code we could use to test the libraries them 
selves? It would be nice to maybe build a really simple executable that 
uses each of the dependencies, so they could be individually tested. At 
least that would narrow down the issue.


It also should be possible to run it under a debugger or something, so 
that we could see where the segfault occurred -- anyone know how to do 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] bdist_mpkg issues

[Christopher Barker]

Russell Owen wrote:
I'll expect our observatory to send me a 10.4 Mac in a few weeks. I plan 
to build the packages on that -- both to assure that the packages will 
run on 10.4 and as a way of testing my released application.


I'm sure the gcc will be rather outdated, but I hope it will be tolerable.


I was having pretty good luck with my 10.4 system when I still had a a 
couple months ago.


All that said, I sure wish I knew what was wrong. bdist_mpkg is not 
getting any attention and at some point it may just break, leaving us 
with no obvious way to build binary installers.


well -- I don't think it does all that much, and the only tricky part 
should be what's also used in py2app, so it may not be that bad.


I suspect the problem is with binary libs, not with bdist_mpkg.

-Chris




Regards,

-- Russell

On Sep 16, 2010, at 2:06 PM, Christopher Barker wrote:


Russell E. Owen wrote:
At your suggestion I built new universal unix libraries using 
MACOSX_DEPLOYMENT_TARGET=10.3. As always, I deleted the dylibs so 
only the static libraries remained (so they would be included in the 
final binary) and I verified that the libraries contained both ppc 
and intel code. I then used bdist_mpkg to build a matplotlib 
installer. Unfortunately I see the same problem as before: when I try 
to import pylab on a 10.3.9 PPC computer I get a segfault.


Darn.

Is there any simple test code we could use to test the libraries them 
selves? It would be nice to maybe build a really simple executable 
that uses each of the dependencies, so they could be individually 
tested. At least that would narrow down the issue.


It also should be possible to run it under a debugger or something, so 
that we could see where the segfault occurred -- anyone know how to do 
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





--
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] Trials with building app

[Christopher Barker]

Chris Weisiger wrote:
Just another update on my travails with making an app build with py2app. 
Since my previous posts haven't attracted much attention, I'm primarily 
posting this on the off-chance that someone else is having similar 
issues and might be helped. However, please do speak up if you have 
something to contribute! I'm starting to get a wee bit frustrated.


This can be frustrating -- it's tricky stuff, and there are apparently 
only a few of us trying to do it.


However, Ronald Oussoren has recently been giving py2app some 
much-needed love. He hasn't responded yet, so he may be busy or on 
vacton, or?? but he did specifically ask us all to let this list know 
when bugs were found.


To build with a nonstandard Python install (necessary to get py2app to 
include the Python interpreter in the build),


What is a non-standard install? you are right that it's won't include 
python if you use the Apple-supplied Python, but it should work with the 
build from python.org -- are you using something else? If so, why?


I have to create a 
main-i386 app template. This is done by going into 
py2app-0.5.2-py2.5.egg/py2app/apptemplate/prebuilt and doing ln -sf 
main-fat3 main-i386


This shouldn't be necessary, so something is up. py2app should just 
work with the exception of having to explicitly specify modules and 
packages sometimes (and data files...).


First, key any any ability to help:

What version of OS-X? what processor, exactly what version/build of 
Python, and what version of py2app?


Second -- have you tried to do the very simplest thing first, with your 
set-up -- a simple hello world app? then you can add in modules that you 
may have problems with one at a time.


This will allow py2app to build the app. However, it won't run, because 
I have a dependency on a .so file which isn't in the default search 
paths that py2app sets up.


Chris Weisiger wrote:
(creatively named processor.app) that errors out on running with this 
error:


ImportError: 
'/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/Crypto/Hash/SHA256.so' 
not found


SHA256.so does exist, in 
./dist/processor.app/Contents/Resources/lib/python2.5/lib-dynload/Crypto/Hash/SHA256.so


However, that is a *.so that is part of Apple's Python ('cause it's in 
System) -- so you don't seem to be completely clean of the Apple 
python. That file does exist in my python.org install, so py2app should 
be able to do the right thing with it.


If you post a simple-as-possilbe-but-still-shos-the-problem example if 
an ap pthat uses SHA, maybe on of us can test it for you.


For example, I've enclosed the simplest test of sha256 I could think of, 
along with a setup.py to build it. It works fine on my 10.5 PPC system 
with the python.org python2.6 (you need to open up the console to see 
the output when it runs)


Does this work for you?

Note that is puts _sha265.so in:

hashlib_test.app/Contents/Resources/lib/python2.6/lib-dynload


Maybe not much help, but you know you aren't alone...

-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


hashlib_test.py
Description: application/python


setup.py
Description: application/python
___
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] Trials with building app

[Christopher Barker]

Chris Weisiger wrote:
This thread suggests that Python is lying about its architecture; 
might be a holdover from using Python2.5 instead of 2.6:

http://old.nabble.com/py2app-architecture-problem-and-System-Python-question-td29262714.html


hmmm -- I'm not sure if Ronald is trying to keep it working with 2.5 
anymore -- there's a  lot of versions to keep track of and test on. I 
recall a discussion of what versions to support on the list, but can't 
find it right now.


You might find this note relevant:

Ronald Oussoren wrote:

Hi,

I've converted the repositories for py2app and related packages to mercurial 
and posted them on bitbucket. The new home pages are:

py2app: http://bitbucket.org/ronaldoussoren/py2app
macholib: http://bitbucket.org/ronaldoussoren/macholib
modulegraph: http://bitbucket.org/ronaldoussoren/modulegraph
altgraph: http://bitbucket.org/ronaldoussoren/altgraph

I have disabled the wiki for now, but did enable the issue tracker.


and my symlink isn't helping as much as I thought it was. Using main-fat 
as main-i386 will generate a working app, though.


glad to hear it!




--
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] How do you tell the system which version to use ?

[Christopher Barker]

Dan White wrote:

I find that I have at least 3 versions of Python on my system.

2 under /System/Library/Frameworks/Python.framework/Versions (2.3 and 
2.5) and one under /Library/Frameworks/Python.framework/Versions (2.7)


Going from Terminal, I get 2.7
Running a script in Scribus, I get 2.3

I found info that says the /System/Library/Frameworks are part of the OS 
installation and that it should not be messed with.


OK.  But how do I get everything to use 2.7 ?


you probably can't with one way !

using the Terminal, which is used depends on your $PATH variable, which 
is set up in your .bash_profile file, which I think gets auto-modified 
by the python installer.


As for Scribus, you'll have to look at the Scribus docs to see how you 
can set which interpreter it uses.


I don't know anything about Python in Scribus, but off the top of my 
head, I'd expect that which version of python it used would be set at 
build time. Python 2.3 was delivered with OS-X 10.4 -- perhaps your 
scribus binary was set up to use 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] [Pyobjc-dev] Py2app too complex?

[Christopher Barker]

Ronald Oussoren wrote:

AFAIK Bob intented py2app to be compatible with py2exe when
specifying what to build. That won't always work though due

 to differences between the two platforms.

There are differences that are because of platform. I think datafiles 
are handles differently at least.


If you want to consider those bugs, I could try to dig into some of my 
setups and identify the issues I've found -- but that won't be for a 
couple weeks at least (vacation!)




It might be useful to think about a cleaner way to specify what to
build, I don't particularly like the current way and especially not when
building more complex applications.


agreed -- though it's no horrible.


I totally agree that is would be better to try to get the various
stand-alone builders to at least share code for the common
functionality. A common API for the various components would help
with that, but it would IMHO be better to actually merge the various
components.


Me too, but that requires cooperation, which may be hard to come by. I'd 
at least contact the ebb-freeze guy (Ralf?) -- he seemed a little 
confused about how to share code -- for instance, he said he couldn't 
use py2exe's code for including the icon because of licensing, but it 
looked like the license was compatible to me. With a little 
encouragement, maybe he'd be glad to share more.


-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

[Christopher Barker]

Ronald Oussoren wrote:

the pyglet sources explicitly load /usr/local/lib/libavbin.dylib using ctypes.  
I could create a py2app recipe that copies libavbin.dylib into the application 
bundle, but that will probably not be used without patching the pyglet sources.



This is a problem in general with all ctypes uses. In fact, ctypes 
reminds me a bit of py2app in the sense that it has some built-in 
algorithms for searching for dynamic libs, and that these fail fairly often.


As for py2app, maybe the ctypes recipe could patch ctypes to look in a 
particular place in teh bundle, and then the user could specify which 
libs ctypes used, and py2ap would put them in the 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 too complex?

[Christopher Barker]

Greg Ewing wrote:

I've been thinking for a while about creating something
simpler that doesn't attempt any automatic module discovery
at all. You would be required to construct a project file
that explicitly lists all the required modules and libraries,
including standard library modules.


I've thought for a while that there is way too much re-invention of the 
wheel with the various stand-alone builders. I'd love to see more 
flexibility, and ideally code sharing, by breaking down the process into 
the various parts:


1) the API for specifying what you need built -- py2app and py2exe at 
least share much )but not all) of this, though they are slightly 
incompatible. AFAIK, the rest are all different


2) Figuring out what needs to be included. py2app and bbfreeze both use 
modulegraph, though bb-freeze apparently forked it.


3) Actually building the bundle -- by definition this will be different 
on different platforms, and there are multiple ways of doing it on one 
platform


Anyway, ideally, each of these steps could share a common API, and so 
each bundle builder could mix and match the parts as they saw fit.


Getting everyone to cooperate is a big social, rather then technical 
problem, but py2app at least could be designed to allow each of these 
pieces to be replaceable. (maybe it already is -- I haven't poked into 
the code enough to know)


So, aside from allowing more code sharing, this approach would make it 
easier to plug in different pieces, like Greg's proposed manual 
specification of modules.


As for that proposal -- I agree with other posters that that really 
would be onerous. However, a hybrid would be great -- run some sort of 
automated tool that outputs an easy-to-read-and-edit text file that 
could be edited, and have the bundle builder use that. Then you culd 
e3dit it, write it frm scratch, whatever you like.


If nothing else, it would really help speed to be able to re-build an 
app without having to go through the process of determining what to 
include each time. I often find myself modifying the source a bit, 
knowing for sure that I haven't changed the dependencies, and then 
having to wait for py2app (or py2exe) to do the full analysis again.


Another idea I have for determining what to include is to take the 
opposite tack of source-code analysis -- run-time analysis:


You would run your app (or better yet, a test suite), and the tool would 
do a run-time examination of what's imported (would that be as simple as 
looking in sys.modules?). That way you would capture the dynamic imports 
that the source-code analysis misses. You would miss the conditional 
imports, but if you have a good test suite, you'd catch those too. (and 
if you don't, you'd have identified a hole in your tests). And you would 
miss the conditional imports that you really don't want ( I never want 
Tk just because I'm using PIL, for instance)


If you really wanted a I-don't-care-how-big-it-is-I-just-want-it-to-work 
version, you could use a superset of runt-time and source-code analysis.



I do want to be clear that py2app has been the best bundle builder I've 
used, and I really appreciate Ronald's effort to bring it up to speed 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   (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

[Christopher Barker]

Ronald Oussoren wrote:

This is a problem in general with all ctypes uses. In fact, ctypes
reminds me a bit of py2app in the sense that it has some built-in
algorithms for searching for dynamic libs, and that these fail fairly often.


Please file bugs for that, I'm pretty sure that ctypes is supposed to
implement the same algoritms as the platform dynamic linker.


IIUC, on OS-X, the full path to a dll is specified when linked -- it 
sure seems that way.


So there is no normal search path.  But anyway, what I've seen is 
pacakges that don't find macports stuff, etc.


I've had to patch the package to make it work at all -- I haven't tried 
to us py2app on any of those yet though. When I do, I'll post a bug 
report here, though.



W.r.t. py2app: I consider cases where py2app doesn't find modules or
shared libraries bugs and should be fixed, either by making the core
smarter or by adding recipes.   Please post reports about issues,
especially when you can reproduce them in smallish examples (or at
least examples that you can share with the outside world).


will do.

But there aer some cases where dynamic importing is simpily goign to 
fail, and you can get a lot of those covered with recipes that bring in 
big 'ol packages that aren't needed, but I'm not sure I always want that.


And if the dynamic import is part of your own code, then it shouldn't be 
a recipe anyway.


But yes, the mainstream packages should all just work.


As for py2app, maybe the ctypes recipe could patch ctypes to look
in a particular place in the bundle, and then the user could
specify which libs ctypes used, and py2ap would put them in the
bundle.


Yes, but that will require some additional trickery to ensure that
ctypes looks in this special location before looking at the full name
specified by the caller.


yup. Maybe not worth it.


Actually finding which libraries are loaded using ctypes will sadly
enough be impossible in general, although recipes could be used for
the popular libaries.


Agreed.

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] py2app and python versions

[Christopher Barker]

Ronald Oussoren wrote:

Hi,

What is the minimal python version that peoply actually use py2app with?


2.6.* for me -- I have some older stuff still on 2.5.*, but I'm 
perfectly happy to port that when I need to update.


Backward compatibility is nice, but if it gets in the way of getting 
things done, it shouldn't be too big a deal to do it -- it's easier to 
port code to a newer python than an older one.


Thanks so much for working 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 updates

[Christopher Barker]

HI folks,

I'm trying to test the latest py2app updates. However, easy_install is 
failing in a number of places. I'm trying:


easy_install py2app==dev

but get errors in the modulegraph dependency.

When I install modulegraph==dev, I get errors in the altgraph dependency.

If I install altgraph, then modulegraph, then py2app, the first two go 
OK, but I get:


No local packages or download links found for modulegraph=0.8

and, indeed, the modulegraph that installed with modulegraph==dev is:

 modulegraph.__version__
'0.7.1'


I'll keep plugging away, and maybe do a straight non-setuptools install, 
but it would be nice if this could get cleaned up.


I'm a bit lost when it comes to setuptools, so I'm not sure I can work 
out a patch.


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

[Christopher Barker]

Christopher Barker wrote:

Hi folks,

I'm trying to test the latest py2app updates. However, easy_install is 
failing in a number of places. I'm trying:


easy_install py2app==dev

but get errors in the modulegraph dependency.


It looks like somehow pypi doesn't know about modulegraph svn (or has 
the wrong info).


Anyway, I got it all from svn, and it built and installed fine. However, 
now I get the following error from py2app:


Not much time to poke into this now, but it reminded my of how we need a 
set of py2app simple test applications. I'll try to make a few of those 
as I poke into this.


-Chris


*** creating application bundle: Maproom ***
Traceback (most recent call last):
  File 
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/py2app-0.4.2-py2.6.egg/py2app/build_app.py, 
line 589, in _run

self.run_normal()
  File 
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/py2app-0.4.2-py2.6.egg/py2app/build_app.py, 
line 660, in run_normal

self.create_binaries(py_files, pkgdirs, extensions, loader_files)
  File 
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/py2app-0.4.2-py2.6.egg/py2app/build_app.py, 
line 755, in create_binaries

target, arcname, pkgexts, copyexts, target.script)
  File 
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/py2app-0.4.2-py2.6.egg/py2app/build_app.py, 
line 1177, in build_executable

for src, dest in self.iter_data_files():
  File 
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/py2app-0.4.2-py2.6.egg/py2app/build_app.py, 
line 475, in iter_data_files

allres = chain(getattr(dist, 'data_files', ()) or (), self.resources)
NameError: global name 'chain' is not defined
 
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/py2app-0.4.2-py2.6.egg/py2app/build_app.py(475)iter_data_files()

- allres = chain(getattr(dist, 'data_files', ()) or (), self.resources)




When I install modulegraph==dev, I get errors in the altgraph dependency.

If I install altgraph, then modulegraph, then py2app, the first two go 
OK, but I get:


No local packages or download links found for modulegraph=0.8

and, indeed, the modulegraph that installed with modulegraph==dev is:

  modulegraph.__version__
'0.7.1'


I'll keep plugging away, and maybe do a straight non-setuptools install, 
but it would be nice if this could get cleaned up.


I'm a bit lost when it comes to setuptools, so I'm not sure I can work 
out a patch.


-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 trunk buglet

[Christopher Barker]

Ronald,

I found the following tiny bug in py2app/build_app.py:

near line 475, there is:

allres = chain(getattr(dist, 'data_files', ()) or (), 
self.resources)


but chain was never defined.

A simple:

from itertools import chain

At the top of the file seems to have fixed 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
Index: py2app/build_app.py
===
--- py2app/build_app.py (revision 80)
+++ py2app/build_app.py (working copy)
@@ -14,6 +14,7 @@
 import shlex
 import shutil
 from cStringIO import StringIO
+from itertools import chain
 
 from setuptools import Command
 from distutils.util import convert_path
___
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 testing modulegraph

[Christopher Barker]

Ronald Oussoren wrote:

Ronald Oussoren wrote:

modulegraph should be platform independent

indeed -- it's used by bbfreeze:

http://pypi.python.org/pypi/bbfreeze/0.96.5

Though I think he's forked it. But it might be good to get in touch and see if 
he's got patches to integrate.


I really don't understand why people think it is a good idea to fork opensource 
packages unless the original author is completely unresponsive and/or moves the 
project in a different direction. Even then I'd let the original author know 
about that.


Neither do I -- indeed I specifically recommended that he report back to 
this list, and maybe even share more code with Py2app, as he was 
interested in making bb-freeze Mac-compatible at one point.


But if he was interested in working more collaboratively, he probably 
wouldn't have started a brand new python bundling project in the first 
place!


Ronald Oussoren wrote:

And they very helpfully even didn't bother to document what they
changed, or which version they forked. That makes comparing the two
unnecessarily hard, and hence I won't bother to do so.


Darn -- what a pain! Have you tried asking him? He's been pretty 
responsive on his list.


By the way -- he did post on this list at one point looking for 
volunteers to work on the Mac version of bb-freeze, and I don't think he 
got any takers.


-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 testing modulegraph

[Christopher Barker]

Ronald Oussoren wrote:

modulegraph should be platform independent


indeed -- it's used by bbfreeze:

http://pypi.python.org/pypi/bbfreeze/0.96.5

Though I think he's forked it. But it might be good to get in touch and 
see if he's got patches to integrate.


-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] Future 64-bit installers

[Christopher Barker]

Ronald Oussoren wrote:


The consensus at the summit was to replace the macosx10.5 installer
(ppc, x86, x86_64) by a macosx10.6 (x86, x86_64) installer for future
releases. That enables linking with Tk 8.5 and that would solve a number
of issues other than being available in 64-bit code.

Users of OSX 10.5 (or earlier) can still use the macosx10.3
installer,  that would stay the same.


So  there will be two:

one for 10.6

one for 10.3.9 -- 10.5?

The later will be same as it's been for ages?

If so, sounds good to me.

Thanks again for all your work on this, Ronald.

-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 problem: invalid matplotlib recipe

[Christopher Barker]

Russell E. Owen wrote:
Removing the line listed above from the recipe fixes the problem -- 


great.

But it also loses the test for the presence of pytz, which may be a bad 
thing (if so, it should also test for dateutils, right?).


I don't think testing for the presence of something is py2apps job. If 
you don't need it, it's OK if it' snot present, and if you do, your app 
tests should catch it.


The point of this sort of recipe is to include stuff that many people 
need, but which are not imported in the usual way, so py2app would 
otherwise miss it.


I suspect that MPL imports pytz differently than it used to, and thus 
this recipe is not longer needed.


Of course, it may still be needed for other versions of MPL, so I don't 
know if we should just strip it out. But I can't remember who wrote it 
when, so I don't know how old a version of MPL you need it for.


-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] [Image-SIG] PIL binaries -- please test

[Christopher Barker]

Matthias Baas wrote:

Apparently, your version of libfreetype doesn't
have the same dependencies as my version. Here, the dependencies are as
follows:

$ otool -L /opt/local/lib/libfreetype.6.dylib
/opt/local/lib/libfreetype.6.dylib:
 /opt/local/lib/libfreetype.6.dylib (compatibility version 10.0.0,
current version 10.20.0)
 /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
(compatibility version 1.0.0, current version 18.0.0)
 
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
(compatibility version 1.0.0, current version 22.0.0)
 /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 88.3.9)


Interesting -- mine are:

$ otool -L  /opt/local/lib/libfreetype.dylib
/opt/local/lib/libfreetype.dylib:
	/opt/local/lib/libfreetype.6.dylib (compatibility version 11.0.0, 
current version 11.0.0)
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current 
version 1.2.5)
	/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.1.5)



so none of the CoreServices stuff - maybe a 10.4 vs. 1.5 difference.



So in the setup script around line 320 where the _imagingft extension
module is defined, I added the following linker args:

  extra_link_args=[-framework, CoreServices, -framework,
ApplicationServices]

After that I can actually import _imagingft just on its own and your
test script then also works


nice work!


So all the dependencies of the PIL modules are now like this:


those look reasonable.


PIL/_imagingtk.so:
/System/Library/Frameworks/Tcl.framework/Versions/8.4/Tcl
(compatibility version 8.4.0, current version 8.4.0)
/System/Library/Frameworks/Tk.framework/Versions/8.4/Tk
(compatibility version 8.4.0, current version 8.4.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 88.3.9)


I'm not sure what the deal is with this -- there are issue with 
different TK versions, but I dont us TK, so I'mve never figured that out.




So do all Python modules compiled on OSX 10.4 automatically work on
newer versions of OSX?


In theory, yes.


Do you want me to send the packages to you for
testing?


Please put them on a publicly accessible site if you can, and sent a 
note tho these lists asking for testing. If you don't have anywhere to 
put them, you can open a Dropbox account, or soemthing else, or send 
them to me and I'll put them on mine.


 By the way, what's generally the preferred distribution format,

zip or dmg?


I suppose dmg is a little better, but either one is fine.

Thanks for all this work!

-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] [Image-SIG] PIL binaries -- please test

[Christopher Barker]

Matthias Baas wrote:

Christopher Barker wrote:

great -- are any of them running 10.4?

I have little time, but here is the short version:

The goal is to get a PIL binary that is statically linked to all of its
dependencies, and those dependencies are all universal (32 bit PPC and
Intel) and linked against the 10.4 sdk (or even the 10.3 one...)
[...]


Finally, I had some time to have a go at this. It builds fine and it
says that every component is available but when I run selftest.py it
seems that some stuff is missing:


*** PIL CORE support not installed


That sure doesn't look good!


*** TKINTER support not installed
--- JPEG support ok
--- ZLIB (PNG/ZIP) support ok
*** FREETYPE2 support not installed
*** LITTLECMS support not installed


neither do those.



Running selftest:
--- 57 tests passed.

The files _imagingcms.so, _imagingft.so, _imagingtk.so are all
available, so I can't say what exactly went wrong with the test.


what about  _imaging.so -- that's the key one.

This is my full set of libs:

_imaging.so
_imagingcms.so
_imagingft.so
_imagingmath.so
_imagingtk.so


Look again at the output when you build -- there's got to be an error in 
there somewhere. And do make sure you clean out the build dir before 
trying again.



So it looks like my build is not really ready for distributing.


nope -- but thanks for workign on it -- I hope yu keep at at. sorry I 
don't have any answers 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] [Image-SIG] PIL binaries -- please test

[Christopher Barker]

Matthias Baas wrote:

Christopher Barker wrote:
Ha! I haven't had a look at selftest.py before. That script requires an
inplace build which I didn't do. Instead, I was pointing PYTHONPATH
inside the build directory


yup -- that will confuse things.


But when I link
against the static lib, the test script only runs fine because it
imports the tk module before the freetype one. Whereas when I just
import _imagingft, I get this:


import PIL._imagingft

Traceback (most recent call last):
  File stdin, line 1, in module
ImportError: dlopen(PIL/_imagingft.so, 2): Symbol not found: _FSOpenResFile
  Referenced from: PIL/_imagingft.so
  Expected in: dynamic lookup

This error does not occur if _imagingtk is imported first. So it looks
like we would have to link against some system library when building
_imagingft.


could be -- I'm clueless on that one, but if I try in it:

 import PIL._imagingft
Traceback (most recent call last):
  File stdin, line 1, in module
ImportError: 
dlopen(/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/PIL/_imagingft.so, 
2): Symbol not found: _inflateEnd
  Referenced from: 
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/PIL/_imagingft.so

  Expected in: dynamic lookup

What I don't know is if we should expect -imagingft to b importable all 
by itself, first. Though I wouldn't think it should depend on TK.


If I do:

 import PIL._imaging
 import PIL._imagingft

it works fine -- which makes sense --you'd never need to import 
_imagingft without importing _imaging first.




By the way, _imaging.so still depends on /usr/lib/libz.1.dylib, but I
suppose as this is a library that ships with OSX, this should be
available on all systems and so it should be fine. Is this correct?


yes -- that's correct.

I'd say if all the self-tests run, you're in pretty good shape.

Try the enclosed test, too -- it uses freetype, without TK (at least not 
explicitly)


-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


SimplePILTest.py
Description: application/python
___
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: more informative error message

[Christopher Barker]

Ralf Gommers wrote:
For numpy and scipy we use bdist_mkg to build dmg installers, and we had 
a user complain about a not so informative error message about a missing 
System Python. 


This has been an issue for along time -- but I never got as far as 
figuring out a patch -- thanks!


I hope Ronald will get a chance to apply it.

-Chris


System Python means from python.org http://python.org
instead of Apple Python, so I can understand the confusion. You can find 
the details in http://projects.scipy.org/scipy/ticket/1177. I propose 
this fix for plists.py:


94c94,99
 title = u'%s requires %s to install.' % (pkgname, name,)
---
  # System python can be interpreted as Apple Python, explain this 
better

  if name.startswith('System Python'):
  title = u'%s requires %s from www.python.org 
http://www.python.org to install.' % (pkgname,
   
name[7:],)

  else:
  title = u'%s requires %s to install.' % (pkgname, name,)

I hope this change can end up in the next bdist_mpkg version.

Also, it would be helpful to have a correct email address on PyPi. I 
contacted Bob Ippolito, who referred me to this list or Ronald Oussoren 
(of whom I have no address).


Best regards,
Ralf Gommers




___
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 query from a naif

[Christopher Barker]

William R. Wing (Bill Wing) wrote:


I know from reading other py2app exchanges on this list that I can't
distribute Apple's binary, and eventually I'll have to replace it with
one from python.org, but I'd like to get py2app running before I tackle
that hurdle.



What am I missing?  Can anyone please help?


partly because of the re-distribution issue, Py2app is set up NOT to 
bundle Apple's Python, so trying to get py2app working with Apple's 
python is a waste of time, if what you want is a bundle with Python 
included.


If you want a re-distributable app bundle, install the Python2.6 from 
Python org, install all the packages you need, get your app running 
there, install py2app into that Python, then build away.


That's really the way to do 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] Which version to use??

[Christopher Barker]

Ronald Oussoren wrote:


To be honest, I'm far from impressed by the quality of the wxWidgets
port to the Mac. I've run into numerous issues in the past where API
calls worked just fine on Windows but failed to work on OSX. That
isn't very helpfull when you want to do the groundwork of a Windows
app using wxWidgets on OSX and do as little as possible on an actual
windows machine.


Being a wx fan, I thought I'd comment. Ronald is absolutely correct -- 
there are platform differences -- there is no substitute for testing 
early and often on all the platforms you want to support. I've found 
that while it's fairly common for s given piece of code to work on one 
platform, but not another, I can usually find a way to write it that 
works everywhere -- and that's usually the documented proper way. i.e. 
you can get away with different errors on the different platforms.


However, while not perfect, what are the alternatives?

If you only want to support the Mac, then by all means use PyObjC -- 
that will give you a fully native application, but it is not an option 
if you want to support other platforms.


pyQT, pyGTK, and tkInter are the other options -- each has its fans, but 
none of them produce native looking and feeling apps on OS-X. wx wraps 
the native libs (Carbon for now, but the next version is Cocoa), so it's 
possible to have truly native Mac apps with wx, that are also native on 
Windows and *nix (of you call GTK native). Note that I say possible, 
because there are lot of details about how you design the apps t make 
them look and feel right on the Mac -- if you neglect those, it won't 
be quite right.


I suppose if you tweak a QT app enough, it might look native, but wx 
does a much better job out of the box.



The other option, of course, is to write multiple GUIs -- my experience 
is that it takes a LOT of code to write a GUI -- so that's a lot of work!


-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] [Image-SIG] PIL binaries -- please test

[Christopher Barker]

Yury V. Zaytsev wrote:

On Tue, 2010-05-25 at 12:57 -0700, Christopher Barker wrote:


If these work well, I think Fredrik will put them on the PIL site.


If you need a permanent mirror in the States, here you go:

http://packages.zaytsev.net/python/


Thanks, though ideally these would be available in a place everyone 
would know to look -- i.e. the PIL site.



What I would want to comment is that it would be nice for you to post
the history script / walk-through / whatever on how you created them, so
that other people would be able to reproduce this if you are busy /
unavailable etc. 


For instance, I have a whole bunch of Macs out there...


great -- are any of them running 10.4?

I have little time, but here is the short version:

The goal is to get a PIL binary that is statically linked to all of its 
dependencies, and those dependencies are all universal (32 bit PPC and 
Intel) and linked against the 10.4 sdk (or even the 10.3 one...)


I achieved all of this except for the 10.4 part...


 = Building the dependencies: =

This ended up being trivial with macports:

sudo port install jpeg +universal
sudo port install lcms +universal
sudo port install freetype +universal


 = Statically linking them when building PIL: =

This is trickier -- it turns out that the PIL setup.py already looks in 
the macports tree for libs. However, gcc prefers dynamic linking, so out 
of the box, it will dynamically link the dependencies -- fine on your 
machine, but not re-distributable.


I THINK there may be a way to tell gcc, through distutils, to statically 
link, but it's hard to find. However, if gcc only finds static libs, 
then it will link those.


In this case, I wasn't using macports for anything else on that machine, 
so what I did is re-name /opt/local/lib, and then create a new one that 
had only static libs in it. then I just ran setup,py build and presto: 
all was well.


The better way to do this would be to edit the setup.py to point to a 
place where the static libs are instead of mangling your macports install.


One other note about 10.4 -- the last time I tried to build teh deps n a 
10.4 machine, I had trouble -- I don't think there are a lot of macports 
devs on 10.4 any more, so it tends to be buggier.


To create the package, run bdist_mpkg, you can get that with easy-install

-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] Which version to use??

[Christopher Barker]

Rodney Somerstein wrote:

If you care about the Mac (particularly in terms of being able to use
PyObjC and/or py2app), stick with 2.x for now.  Otherwise, it doesn't
matter much which exact version of 3.x you use.


This brings up a question for me as to what the state of Python is on 
the Mac. Python 3.x has been a available for quite awhile. I see on 
Python.org that 3.1.2 is listed as the current download for the Mac. 
What exactly is the current state of this? What doesn't work on the Mac 
in Python 3 and what are current plans related to this?


Honestly, I don't know if the Mac is in any poorer position with regard 
to Python 3 as any other platform.


NONE of the major packages I use have been ported to Py3 on any 
platform: numpy, SciPy, wxPython. Many of those are well supported on 
the Mac, so I don't think there will be any issues there.



The Mac Python community seems pretty small.


There are a LOT of folks using Python on teh Mac -- the community that 
is pretty small is the community of folks doing mac-specific stuff -- 
PyObjC, for instance. It getting to be that the the fradction of 
development that is done for desktop apps is pretty small -- and that 
that is done is often done with cross-platfrom tools.


The only folks that care about py2app are folks doing desktop 
development and the only folks that care about PyObjC are folks doing 
desktop development for Mac-only applications.


If that is what you want to do, then you are right, the community is 
pretty small -- is there a larger one built around an open-source 
dynamic language? I have no idea.


Given that Python seems to 
position itself as a major programming and scripting language, it seems 
rather strange that there is so little effort placed into providing 
first class support for the second most popular computing platform.


It does have first class support for scripting, command line stuff, web 
app development, etc -- one reason the there are so many more users of 
Python on the Mac than there are folks on this list is that all that 
stuff just works.


-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] PIL binaries -- please test

[Christopher Barker]

Hi folks,

Much to my surprise, I had a little time to build some PIL binaries:

http://dl.dropbox.com/u/855965/PIL-OSX-Binaries/PIL-1.1.7-py2.5-macosx10.5.mpkg.zip

http://dl.dropbox.com/u/855965/PIL-OSX-Binaries/PIL-1.1.7-py2.6-macosx10.5.mpkg.zip

I'd really like folks to test them on as many different systems as possible.

You can see these are for python 2.5 or 2.6, build with and for the 
python.org python binaries. They should have all dependencies statically 
linked.


I built them on OS-X 10.5 (leopard), so they may not work on 10.4 I'd 
love if someone could test and see if they do, however, I no longer have 
a 10.4 system to test on.


I do expect them to work on 10.5 and 10.6, PPC and Intel.

Please let me know if you test, whether it worked or not, and on what 
system/python.


If these work well, I think Fredrik will put them on the PIL site.

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] Which version to use??

[Christopher Barker]

Rodney Somerstein wrote:
Hopefully things will start to fall into place for Python 3.x. 
I see questions on comp.lang.python and elsewhere from people wanting to 
use Python 3.x as their main development language. I think many people, 
such as myself, are reluctant to jump into Python right now. My 
perception is that 2.x has a limited life span.


Limited, yes, but long -- it is the primary version for most users now 
-- it will be maintained for a good while.


best choice to jump into that right now when the 3.x branch of the 
language itself is where most work seems to be going on. However, as you 
noted, many packages aren't trivial to port and that seems to be going 
very slowly.


Which contradicts your perception -- there are two types of work being done:

 - development of the language itself -- yes, that is the 3.x branch

 - development of third-party packages -- this is moving slowly to 3.x, 


   but every one I'm involved with is making great effort to keep things
   2.x compatible as they develop for 3.x

 - development of applications with python -- still mostly 2.x

The 2 to 3 transition is a much bigger deal for extension packages -- 
ones that cal into the C runtime, than it is for application code.


In short -- fire up 2.6.5, and code away -- I'm quite confident you will 
be supported as you move forward.



How far away is Python 3 from being the main branch of the language? Are 
we talking another year? 2? 5?


I'm going to guess about 2 years until it's the first choice for new 
projects, and 5 or more before most projects have ported to it -- and 
that is a totally uneducated guess!


In part, due to the fact 
that packaging seems to be trickier for people to figure out with py2app 
than with py2exe I have gotten that impression.


I've always found py2app to be easier to use, actually.

The only thing really missing once that is done is 
a port of a good cross-platform UI library, such as wxWidgets, so that 
cross-platform apps can be developed easily.


yup -- for me, I think wx will be the last one I rely on to get ported. 
Oh well. It's a big package!


-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] PIL binaries -- please test

[Christopher Barker]

Matthias Baas wrote:

Christopher Barker wrote:

Much to my surprise, I had a little time to build some PIL binaries:

http://dl.dropbox.com/u/855965/PIL-OSX-Binaries/PIL-1.1.7-py2.5-macosx10.5.mpkg.zip
http://dl.dropbox.com/u/855965/PIL-OSX-Binaries/PIL-1.1.7-py2.6-macosx10.5.mpkg.zip



I built them on OS-X 10.5 (leopard), so they may not work on 10.4 I'd
love if someone could test and see if they do, however, I no longer have
a 10.4 system to test on.


I tried the py2.6 binary on OSX 10.4. The package installs fine but it
can't really load an image. When I open a jpg, I can read its size but
as soon as I try to load the data, I get an import error:

ImportError: The _imaging C module is not installed

When I try to import _imaging manually I get:

ImportError: dlopen(./_imaging.so, 2): Symbol not found: _clock$UNIX2003
  Referenced from: ./_imaging.so
  Expected in: dynamic lookup


Thanks for testing -- it's pretty much what I expected. I build libjpeg 
will macports, and it linked it against the 10.5 system libs. It's 
certainly possible to build libs that are 10.4 compatible, but it's a 
pain to do on a 10.5 machine.


I don't have much time, so these will remain 10.5 and above binaries, 
unless someone steps up to build universal versions of the dependencies 
that work with 10.4.


NOTE: it was trivial to build them with macports on 10.5. However, last 
time I tried on 10.4, I had trouble. But if you have a 10.4 system and 
want to give it a try:


$ sudo port install jpeg +universal

and see if it works -- if it does, try the other dependencies (I think 
it's freetype, zlib, and lcms -- see the PIL README)


Fredrik -- it's up to you what you want to post on your site, but if we 
hear from some others that they work for them, you might want to post 
these, making it clear they work only for the python.org binaries and 
OS-X 10.5 and above.


For what it's worth, I built these on an Intel 10.5 system and they work 
there and on my PPC 10.5 system, so that's a start.


-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] Shell login for py2app bundle

[Christopher Barker]

Aahz wrote:

On Fri, Mar 19, 2010, Dan Ross wrote:

I'm trying to call Imagemagick's convert through a subprocess from within
a bundled app.

Console.app is telling me that it can't find it in /bin/sh which stands to
reason.

I can change the convert command to /usr/local/bin/convert in the app
but then when convert calls Ghostscript (gs) it can't find IT in /bin/sh.

Suggestions?


PIL?


right, or the python bindings to Image Magic.

Anyway, that aside, there may be other reasons to call command line 
apps. I think your choices are:


1) hard-code the full paths
  - but this will only work if every system you run it on has them in 
the same places.


2) set a PATH environment variable, with at least the standard path in it:

/bin:/usr/bin:/usr/local/bin

you may want to add some in there for macports or fink, too.

I suppose you could even import the users .bash_rc or something, and get 
it that way.


Depending on how you are calling the command line tools, there much be a 
way to set environment variables -if nothing else, add the:


PATH=/bin:/usr/bin:/usr/local/bin

right before your command.

-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] Fun with py2app and OpenGL

[Christopher Barker]

R Fritz wrote:
Explicitly including packages 'photom' (mine) and 'OpenGL' (published) 


why did you explicitly include them? They should have been picked up by 
py2app unless you import them in an odd way.


I've got an OpenGL app bundling up fine without any tricks, and it puts 
OpenGL into:


Maproom.app/Contents/Resources/lib/python2.5/OpenGL/

maybe there is a py2app recipe that handles 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] Recommended Tcl/Tk with Py-2.6.x? (was: Test failure...)

[Christopher Barker]

Tom Loredo wrote:

Chris wrote:

wxPython is 32 bit, you need to use it with 32 bit Python.


* At the very top of the wxpython page:

(8-Oct-2008) A set of wxPython binaries for Python 2.6 on the Mac and Windows
(32-bit and 64-bit) are now available.


I guess that should read:

A set of wxPython binaries for Python 2.6 on the Mac (32 bit) and 
Windows (32-bit and 64-bit) are now available.


English can lack precision.


* On the wxpython download page:

http://www.wxpython.org/download.php#binaries

the Mac section says not a word about 32- vs 64-bit.


That's 'cause there is only one build, but a bit more text could help.


* Google:

wxpython Snow Leopard

Does that look very clear or promising?


I agree that that looks painful, but here's my take on it:

Nothing about snow leopard breaks wxPython -- what breaks wxPython is 
the Python that Apple ships with Snow Leopard. The answer to that is 
simple: DO NOT USE Apple's Python.


I have never used it is has always been broken one way or another -- the 
Python/MacPython community has no say or control over what Apples does, 
and they have consistently broken all kinds of stuff in their build. On 
Leopard, they got it very, very close, but they still have never updated 
a version, and don't seem to be careful about compatibility, etc.


The truth is, while it sounds great that Apple provides python, they 
have never treated like a real, supported system component for third 
party use.


If you want wxPython and any number of other assorted third party 
packages, use the python.org build, it's as simple as that.



* Apple's Python on SL is 64-bit by default; unless a user
understands the 32-bit compatibility and has also figured out
how to use Apple's proprietary mechanism to switch Python to
32-bit, they will not have an easy time with Apple's Python
and wxpython.


exactly --so don't use it!

  The actual situation may be straightforward, but potential users

should not have to stumble upon a mailing list posting to figure
out what will work.


doc/wiki patches accepted. The binary download section of the wxPython 
page could use some updating.



32-bit Python will be fine for me for the time being, so I'm
glad to learn what will work.  But some of my time series work
is pressing closer to the 32-bit boundary.


Yes, it would be nice to get 64 bit support -- it's a tough transition 
-- but partly Apple is to blame, they decided not to build a 64 bit Carbon.



Also, as long as
those with some expertise with what goes on under the covers
(and Chris has 10^3 times my expertise) don't push on 64-bit to
see what breaks when and where, 64-bit will never happen.


well, I'm too dependent on wx, and not nearly enough of an expert to 
work on wxOSX (Cocoa-based) -- so all I can do is wait for now. I think 
it's looking pretty promising, though.



It's a SL thread, but still I'm glad to learn what combinations
work.  Can you let us know exactly what is working for you?
Leopard?  Apple's Python or Python.org or a new build?  Which
Python version?  Which numpy/scipy/mpl versions?  (This should
probably be another thread!


As far as I know, everything that works on older systems works on Snow 
Leopard, so all you need to do is install the standard binaries:


Python from python.org
wxPython from wxPython.org
MPL from the MPL project
numpy from the numpy project

Do you see a theme, here?

It gets tough if you want to use Apple's Python or build stuff yourself 
on Snow Leopard -- it's always been a pain to build for older systems on 
a Mac, though it sounds like it's even worse than usual with Snow Leopard.



On a related topic, Kevin noted:

many people can't get their 64-bit 
Python GUI apps to build with py2app.


yup, there are still issues. The trick is that there just isn't that 
large a community doing this stuff. There are a lot of folks using 
python on the Mac, but apparently they are doing mostly web development 
and other non-gui unix-y stuff, where there are simply fewer issues.


The funny thing for me is that my IT folks are making me upgrade to 
Leopard (from tiger), 'cause Apple has stopped providing security 
patches, but they won't let go right to Snow Leopard, 'cause they don't 
have a standard configuration defined for that yet -- what a pain!


Having a total of 4 architectures for the Mac does NOT make this easy!

-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