Re: [matplotlib-devel] [Anaconda Support] OSX: why not make "python" invoke the framework?

[Chris B. <chr...@no...>]

On Thu, Aug 21, 2014 at 3:53 PM, Aaron Meurer <aar...@co...>
wrote:

> The only potential issue I can think of for making python=pythonw is
> that pythonw is a shell script:
>

I agree -- that could create issues (though will mostly work, I suppose)

But somehow the python.org build has managed to make a pythonw that IS a
proper executable:

ORRW-M-1275474:bin chris.barker$ pwd
/Library/Frameworks/Python.framework/Versions/2.7/bin

ORRW-M-1275474:bin chris.barker$ ls -l pythonw
lrwxr-xr-x  1 root  wheel  8 Jul 16  2013 pythonw -> pythonw2

ORRW-M-1275474:bin chris.barker$ ls -l pythonw2
lrwxr-xr-x  1 root  wheel  10 Jul 16  2013 pythonw2 -> pythonw2.7

ORRW-M-1275474:bin chris.barker$ ls -l pythonw2.7
-rwxr-xr-x  1 chris.barker  admin  9180 May 13  2013 pythonw2.7

ORRW-M-1275474:bin chris.barker$ file  pythonw2.7
pythonw2.7: Mach-O executable i386

(yes, ti works for 64 bit too -- this just happens to be what I have)

It would be nice if Anaconda would do it the same way.

-Chris







> #!/bin/bash
> export PYTHONEXECUTABLE=/Users/aaronmeurer/anaconda/bin/python
> /Users/aaronmeurer/anaconda/python.app/Contents/MacOS/python $@
>
> This is needed because otherwise Python thinks its sys.prefix is
> ../../ from the executable, i.e.,
> /Users/aaronmeurer/anaconda/python.app/Contents/MacOS
>
> $~/anaconda/python.app/Contents/MacOS/python
> Python 3.4.1 |Continuum Analytics, Inc.| (default, Aug 11 2014, 14:17:03)
> [GCC 4.2.1 (Apple Inc. build 5577)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import sys
> >>> sys.prefix
> '/Users/aaronmeurer/anaconda/python.app/Contents'
>
> I'm not sure what kinds of issues this would cause having python be a
> shell script rather than a Mach-O 64-bit x86_64 executable (or a
> symlink to a Mach-O 64-bit x86_64 executable).
>
> I suppose you could do this (replace 3.4 with 2.7 if you use Python 2):
>
> $mv ~/anaconda/bin/python3.4 ~/anaconda/bin/python3.4-orig
> $ln -s ~/anaconda/bin/pythonw /Users/aaronmeurer/anaconda/bin/python3.4
>
> and see if anything breaks (or if you don't want to risk breaking your
> main Python install, do it in a separate conda environment).
>
> Aaron Meurer
>
> On Fri, Aug 15, 2014 at 2:37 PM, Derek Homeier
> <de...@as...> wrote:
> > On 14 Aug 2014, at 11:40 pm, Chris Barker <chr...@no...> wrote:
> >
> >> On Thu, Aug 14, 2014 at 12:07 PM, Eric Firing <efi...@gm...>
> wrote:
> >>  but as far as I can see, on OSX, there is no *advantage* to
> non-framework python.  Is this correct?
> >>
> >> Suggestion for anaconda:
> >> make bin/python a link to ../python.app/Contents/MacOS/python
> >>
> >> NOTE: the python.org python build has been doing this (or something
> like it) for years and many versions -- I had gotten pretty used to it and
> was pretty annoyed when I discovered Anaconda keeps anon-framework binary
> as the default.
> >>
> >> It was annoying enough that I had to explicitly call pythonw (or alter
> the #! line) for my wxPython scripts, but with ipython it's even worse --
> how would I start up ipython with a framework build?
> >>
> >> NOTE: if the Anaconda folks really think there is a real downside to
> using the framework executable for the default python, maybe the ipython
> start up script could use pythonw ?
> >>
> >> Eric - have you tried recent MPL with the python.org builds to confirm
> the issue? I'm a bit surprised that it would even semi-work -- when I try
> wxPython with the regular executable, I get an error message and it wont
> run at all.
> >>
> > Just to make sure I understand - this is about whether the MPL macosx
> backend would run with non-framework
> > Python at all? It certainly should not, as _macosx.m has been enforcing
> an error in this case for some versions.
> > That put aside, when I disable the error at the end of _macosx.m I found
> the OSX backend to still work as it used
> > to under OS X 10.9 with the Fink Python installation (which is not built
> as a framework, and unfortunately unlikely
> > to change in foreseeable time). I.e. the only obvious problem is the
> lack of control by the window manager.
> > Overall I still find it to perform better than any of the alternative
> backends. But having switched to PyQT4 as the
> > default backend due to the above Fink troubles, I did notice some
> oddities under Mavericks. I have no idea if they
> > are related to the problems Eric had originally reported, but they are
> clearly Mavericks-specific:
> >
> > When using MPL with ipython --pylab and the Quartz version of PyQT4, the
> interpreter seems to be slow down
> > extremely after running for a little while. Weirdly this is not
> connected to any graphics display and in fact happens
> > even without any plotting window opened, i.e. the ipython shell just
> randomly becomes completely unresponsive
> > and hangs for several seconds on simple tasks like typing or navigating
> through history. The plotting itself actually
> > does not appear to perform any worse than it used to under Mountain Lion.
> > None of this seems to occur with the X11 variant of PyQT4.
> > When launching ipython without the --pylab flag and loading MPL later
> (e.g. with 'import matplotlib' in the ipython
> > profile), none of these stalls or hangups occur, but plots sometimes
> seem not to refresh properly even with a
> > plt.draw() and one has to manually resize the plot window to force
> redrawing of the figure.
> > This might be primarily a PyQT4 or Ipython issue, but obviously it is
> somehow connected to the pylab mode of Ipython.
> >
> > Cheers,
> >                                         Derek
> >
> > --
> > Anaconda Community Support Group Brought to you by Continuum Analytics
> > ---
> > You received this message because you are subscribed to the Google
> Groups "Anaconda - Public" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to ana...@co....
> > To post to this group, send email to ana...@co....
> > Visit this group at
> http://groups.google.com/a/continuum.io/group/anaconda/.
>



-- 

Christopher Barker, Ph.D.
Oceanographer

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

Chr...@no...