Disappearing menubar

[ChrisBeaumont]

When I went to test #593 on my new laptop (OSX mavericks), I noticed that the menubar doesn't appear until you click on another window and click back to the glue window. I wonder how reproducibile this is on other OS versions?

[astrofrog]

@ChrisBeaumont - just to be clear, do you see this issue in master too, or only #593? WIll try and reproduce here.

[ChrisBeaumont]

It happens on master, too

[astrofrog]

Just to add a datapoint, I don't see the issue on OS 10.8.

[astrofrog]

@aagoodman saw the same issue

[astrofrog]

I posted a message to the PyQt mailing list with a minimal example.

[astrofrog]

Well I went down the rabbit hole and long story short it looks like it's that python vs pythonw thing. On MacOS X 10.8 it seems to not matter, but on 10.10 I found that if I install glue with conda, if I run

/Users/tom/miniconda3/envs/production/bin/glue

the menu doesn't appear, while

pythonw /Users/tom/miniconda3/envs/production/bin/glue

does work. Interestingly, ipython qtconsole doesn't seem to suffer from the same issue (or at least I think it did a little when I was testing, but can't reproduce that now), and in the ipython script, the first line is:

#!/bin/bash /Users/tom/miniconda3/envs/production/bin/python.app

while the first line of the glue script is:

#!/Users/tom/miniconda3/envs/production/bin/python

If I change the first line of the glue script to the .app version, then suddenly it works again.

So for conda, I think there must be a patch that gets applied to IPython, I've asked about that

Otherwise, I'm not sure how we force pythonw or python.app to get used when we install e.g. from master.

@ChrisBeaumont - does this ring any bells from when you looked into the pythonw stuff before?

[astrofrog]

Oh, finally figured out what was missing in conda! http://conda.pydata.org/docs/building/meta-yaml.html#python-app

[ChrisBeaumont]

like it's that python vs pythonw thing

ugh. I'm so peeved with how anaconda handles that, since the two binaries are identical for the system python.

~ > md5 /usr/bin/python /usr/bin/pythonw
MD5 (/usr/bin/python) = ed1bd7f85be2f9973e0c7cacfaa4e426
MD5 (/usr/bin/pythonw) = ed1bd7f85be2f9973e0c7cacfaa4e426

[ChrisBeaumont]

Oh, finally figured out what was missing in conda! http://conda.pydata.org/docs/building/meta-yaml.html#python-app

Well that's at least nice. But it probably doesn't help if someone pip installs or builds from source (I imagine they still need to invoke via pythonw -m pip or pythonw setup.py install)

[astrofrog]

Yeah, it's frustrating :( MacPorts also has the two binaries the same which is why it also works.

Sadly, pythonw setup.py install doesn't work for Anaconda either :(

[astrofrog]

Oh man, to make things worse it turns out the reason it doesn't work is because pythonw in conda is just a script that does:

#!/bin/bash
export PYTHONEXECUTABLE=/Users/tom/miniconda3/envs/production/bin/python
/Users/tom/miniconda3/envs/production/python.app/Contents/MacOS/python "$@"

and if you comment out the export line, it works!

[ChrisBeaumont]

I'd be really interested to know what problems are actually solved by having two distinct binaries.

[astrofrog]

@ChrisBeaumont - me too. I've reported this as an issue (the resetting of the PYTHONEXECUTABLE path). Let's see what they say.

[astrofrog]

The good news is that the conda package for glue is now fixed, so at least that's one thing out of the way.

[ChrisBeaumont]

(apparently GH interprets "doesn't close #issue" as "close #issue" :) )

[astrofrog]

😆