From matthew.brett at gmail.com Sat Aug 2 20:48:40 2014 From: matthew.brett at gmail.com (Matthew Brett) Date: Sat, 02 Aug 2014 11:48:40 -0700 Subject: [Pythonmac-SIG] MacPython and automating wheel builds Message-ID: <53dd328845491_48b93fd8b3f3268899768@shanghai.local.mail> Hi, I would like some feedback on an idea I had for providing a wheel-building service via the MacPython organization. Following up an idea and code by Matt Terry [1], I've made a general repo called 'terryfy', with tools for building Python projects on the travis-ci OSX virtual machines [2]. Meanwhile, Olivier Grisel from scikit-learn kindly gave me access to the scikit-learn rackspace account for uploading built wheels. This made it rather easy to make a series of repos to build OSX wheels automatically. An example is the 'h5py-wheels' repo [3], to build OSX wheels for the h5py project. The idea of projects like these is that the (e.g) h5py release manager can click on the travis-ci webpage 'Restart build' button [4] or make a commit to the 'h5py-wheels' repo into order to trigger a build / test / upload of OSX wheels from travis-ci VMs to the rackspace hosted directory at http://wheels.scikit-image.org/ . From there they can upload to pypi for the release. There are currently terryfy-based wheel-building projects for h5py [3], numpy / scipy [5], matplotlib [6], cython [7], scikit-image [8], scikit-learn [9], pandas [10], Pillow [11], tornado [12], numexpr [13] and Markupsafe [14]. These all build wheels against the Python.org Python. I think this could be a big improvement for releasing OSX packages, but, at the moment, the process relies on me being available to maintain and trigger builds, as the owner of most of the building repos. So, I was wondering if y'all agreed that it was sensible to start transferring these repos to the MacPython organization. The idea would be that someone with a project on PyPi that wanted to build OSX wheels, could start off by making their own repo to build the wheels and test, based on the templates above. I have a script that partly automates this at [15]. Once the build and test phase is working, the owner transfers the repo to the MacPython organization, and I or someone else with the rackspace credentials adds the ability to upload the built wheels to the rackspace directory. The previous owner is a collaborator on the repository so they can push commits and trigger builds. In this way, we could have a collection of say 25 MacPython organization repos that would provide an OSX wheel-building service to projects that need it. It could be a central point for advice and help on building OSX wheels. Thanks for any feedback, Matthew [1] https://github.com/matplotlib/mpl_mac_testing [2] https://github.com/matthew-brett/terryfy [3] https://github.com/matthew-brett/h5py-wheels [4] https://travis-ci.org/matthew-brett/h5py-wheels [5] https://github.com/matthew-brett/numpy-atlas-binaries [6] https://github.com/matthew-brett/matplotlib-wheels [7] https://github.com/matthew-brett/cython-wheels [8] https://github.com/scikit-image/scikit-image-wheels [9] https://github.com/matthew-grett/scikit-learn-wheels [10] https://github.com/matthew-grett/pandas-wheels [11] https://github.com/python-Pillow/pillow-wheels [12] https://github.com/matthew-brett/tornado-wheels [13] https://github.com/matthew-brett/numexpr-wheels [14] https://github.com/matthew-brett/markupsafe-wheels [15] https://github.com/matthew-brett/terryfy/blob/master/make-wheel-builder -- Sent from Vmail From matthew.brett at gmail.com Sun Aug 3 02:13:40 2014 From: matthew.brett at gmail.com (Matthew Brett) Date: Sat, 02 Aug 2014 17:13:40 -0700 Subject: [Pythonmac-SIG] New page on wiki about system Python Message-ID: <53dd7eb447c21_48b93fd8b27b68601012a4@shanghai.local.mail> Hi, I just put up a new wiki page on why system Python can be incovenient to use: https://github.com/MacPython/wiki/wiki/Which-Python I'd be very happy for feedback as to whether this is still the standard advice, Cheers, Matthew -- Sent from Vmail From amorris at mistermorris.com Sun Aug 3 02:28:04 2014 From: amorris at mistermorris.com (Adam Morris) Date: Sun, 3 Aug 2014 08:28:04 +0800 Subject: [Pythonmac-SIG] New page on wiki about system Python In-Reply-To: <53dd7eb447c21_48b93fd8b27b68601012a4@shanghai.local.mail> References: <53dd7eb447c21_48b93fd8b27b68601012a4@shanghai.local.mail> Message-ID: Concur, seems like the best practice way to install python is with brew. Sent from my iPhone > On Aug 3, 2014, at 8:13 AM, Matthew Brett wrote: > > Hi, > > I just put up a new wiki page on why system Python can be incovenient to > use: > > https://github.com/MacPython/wiki/wiki/Which-Python > > I'd be very happy for feedback as to whether this is still the standard > advice, > > Cheers, > > Matthew > > -- > Sent from Vmail > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > https://mail.python.org/mailman/listinfo/pythonmac-sig > unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG From kw at codebykevin.com Sun Aug 3 20:13:02 2014 From: kw at codebykevin.com (Kevin Walzer) Date: Sun, 03 Aug 2014 14:13:02 -0400 Subject: [Pythonmac-SIG] New page on wiki about system Python In-Reply-To: <53dd7eb447c21_48b93fd8b27b68601012a4@shanghai.local.mail> References: <53dd7eb447c21_48b93fd8b27b68601012a4@shanghai.local.mail> Message-ID: <53DE7BAE.30805@codebykevin.com> On 8/2/14, 8:13 PM, Matthew Brett wrote: > Hi, > > I just put up a new wiki page on why system Python can be incovenient to > use: > > https://github.com/MacPython/wiki/wiki/Which-Python > > I'd be very happy for feedback as to whether this is still the standard > advice, For heavy development and projects that will deployed elsewhere, it's probably better to use a new installation. However, for casual programming, the system Python is fine. --Kevin -- Kevin Walzer Code by Kevin/Mobile Code by Kevin http://www.codebykevin.com http://www.wtmobilesoftware.com From charlie.clark at clark-consulting.eu Mon Aug 4 11:24:26 2014 From: charlie.clark at clark-consulting.eu (Charlie Clark) Date: Mon, 04 Aug 2014 11:24:26 +0200 Subject: [Pythonmac-SIG] New page on wiki about system Python In-Reply-To: References: <53dd7eb447c21_48b93fd8b27b68601012a4@shanghai.local.mail> Message-ID: Am .08.2014, 02:28 Uhr, schrieb Adam Morris : > Concur, seems like the best practice way to install python is with brew. It's a bit too long. The recommended alternatives to the system Python are: * from Python.org (comes with Python Launcher) * MacPorts * Brew Having not used the Apple Python I don't really know if it still routinely contains bugs because of the way Apple massages the POSIX stuff. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a D?sseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 From chris.barker at noaa.gov Mon Aug 4 18:05:06 2014 From: chris.barker at noaa.gov (Chris Barker) Date: Mon, 4 Aug 2014 09:05:06 -0700 Subject: [Pythonmac-SIG] MacPython and automating wheel builds In-Reply-To: <53dd328845491_48b93fd8b3f3268899768@shanghai.local.mail> References: <53dd328845491_48b93fd8b3f3268899768@shanghai.local.mail> Message-ID: Matthew, I would like some feedback on an idea I had for providing a > wheel-building service via the MacPython organization. > Do you mean the gitHub MacPython organization? If so, then yes, this is exactly the kind of thing I had in mind when I started that. Following up an idea and code by Matt Terry [1], I've made a general > repo called 'terryfy', with tools for building Python projects on the > travis-ci OSX virtual machines [2]. > > Meanwhile, Olivier Grisel from scikit-learn kindly gave me access to the > scikit-learn rackspace account for uploading built wheels. > > This made it rather easy to make a series of repos to build OSX wheels > automatically. An example is the 'h5py-wheels' repo [3], to build > OSX wheels for the h5py project. > One thought on this -- I had envisioned one repo that would contain the stuff to build a whole bunch of projects -- not one per project. One reason is that ere is a lot of shared effort -- for instance, there are multiple packages that require the HDF5 libs -- the code to build HDF5 itself should be shared, ideally. This may not work with with the travis links -- if everything in a repo would need to be rebuilt when only one had been changed, though. > There are currently terryfy-based wheel-building projects for h5py > [3], numpy / scipy [5], matplotlib [6], cython [7], scikit-image [8], > scikit-learn [9], pandas [10], Pillow [11], tornado [12], > numexpr [13] and Markupsafe [14]. These all build wheels against the > Python.org Python. > great work! So, I was wondering if y'all agreed that it was sensible to start > transferring these repos to the MacPython organization. > yes -- it makes loads more sense to spread the load here. In this way, we could have a collection of say 25 MacPython organization > repos that would provide an OSX wheel-building service to projects that > need it. It could be a central point for advice and help on building > OSX wheels. > sounds good to me. Thanks for putting all this effort in! -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Thu Aug 7 02:27:59 2014 From: matthew.brett at gmail.com (Matthew Brett) Date: Wed, 06 Aug 2014 17:27:59 -0700 Subject: [Pythonmac-SIG] MacPython and automating wheel builds References: Message-ID: <53e2c80fe81d9_a97b3fe829e1b9907033c@shanghai.local.mail> On Mon, Aug 04, 2014 at 09:05 AM, Chris Barker wrote: > from: Chris Barker > date: Mon, Aug 04 09:05 AM -07:00 2014 > to: Matthew Brett > cc: Pythonmac-Sig , Olivier Grisel > subject: Re: [Pythonmac-SIG] MacPython and automating wheel builds > > Matthew, > > I would like some feedback on an idea I had for providing a >> wheel-building service via the MacPython organization. >> > > Do you mean the gitHub MacPython organization? If so, then yes, this is > exactly the kind of thing I had in mind when I started that. > > Following up an idea and code by Matt Terry [1], I've made a general >> repo called 'terryfy', with tools for building Python projects on the >> travis-ci OSX virtual machines [2]. >> >> Meanwhile, Olivier Grisel from scikit-learn kindly gave me access to the >> scikit-learn rackspace account for uploading built wheels. >> >> This made it rather easy to make a series of repos to build OSX wheels >> automatically. An example is the 'h5py-wheels' repo [3], to build >> OSX wheels for the h5py project. >> > > One thought on this -- I had envisioned one repo that would contain the > stuff to build a whole bunch of projects -- not one per project. One reason > is that ere is a lot of shared effort -- for instance, there are multiple > packages that require the HDF5 libs -- the code to build HDF5 itself should > be shared, ideally. I'm hoping to do that with the 'terryfy' repo. For example, here are the relevant lines from the h5py-wheel building repo travis file: - standard_install szip $SZIP_VERSION .tar.gz szip- --enable-encoding=no - standard_install hdf5 $HDF5_VERSION .tar.bz2 hdf5- --with-szlib=$BUILD_PREFIX where the szip and hdf5 source libraries are in the 'archives' subdirectory of the repo, and "standard_install" is a bash function defined in the "library_installers.sh" file of "terryfy". If the installation starts to get more complicated than a couple of lines we could add the recipe to the "library_installers.sh" file as a function - e.g "install_hdf5". > This may not work with with the travis links -- if everything in a repo > would need to be rebuilt when only one had been changed, though. I've more or less avoided trying to optimize build time on the basis that build time is fairly cheap, and I wanted to get the builds working as fast as I could. I could imagine having some builds depend on others, and build artefacts going into the Rackspace account somewhere to be picked up by other builds, but it might be complicated to arrange build triggering. > >> There are currently terryfy-based wheel-building projects for h5py >> [3], numpy / scipy [5], matplotlib [6], cython [7], scikit-image [8], >> scikit-learn [9], pandas [10], Pillow [11], tornado [12], >> numexpr [13] and Markupsafe [14]. These all build wheels against the >> Python.org Python. >> > > great work! Thanks - time consuming, but mostly fairly easy work, luckily, with most of the ideas in what Matt Terry did already. > So, I was wondering if y'all agreed that it was sensible to start >> transferring these repos to the MacPython organization. >> > > yes -- it makes loads more sense to spread the load here. > > In this way, we could have a collection of say 25 MacPython organization >> repos that would provide an OSX wheel-building service to projects that >> need it. It could be a central point for advice and help on building >> OSX wheels. >> > > sounds good to me. Thanks for putting all this effort in! Great - so I'm planning to transfer the building repos to the MacPython organization over the next few days. I hope we can use the scikit-learn rackspace account, but I'll check with Olivier. Cheers, Matthew -- Sent from Vmail From chris.barker at noaa.gov Fri Aug 22 22:48:15 2014 From: chris.barker at noaa.gov (Chris Barker) Date: Fri, 22 Aug 2014 13:48:15 -0700 Subject: [Pythonmac-SIG] What does it take to run a GUI app? Message-ID: Folks, Over on the list for the Anaconda distribution, we've run into a limitation in our understanding of the whole app bundle, etc business. The problem is thus: Anaconda is currently built with the old python / pythonw dichotomy. python is a standard unix-style executable -- great for command line apps, web servers, what have you. But you get the dreaded: """ This program needs access to the screen. Please run with a Framework build of python, and only when you are logged in on the main display of your Mac. """ when you try to run a GUI app (this error message from wxPython) pythonw, on the other hand, is a shell script that re-directs to a python that is inside a hand-built application bundle: #!/bin/bash export PYTHONEXECUTABLE=/Users/chris.barker/PythonStuff/Anaconda/anaconda/bin/python /Users/chris.barker/PythonStuff/Anaconda/anaconda/python.app/Contents/MacOS/python $@ This all sort-of works. But it's a pain, because you may not know when you start up an app, whether it needs to access the Window manger (like iPython, for instance). And now I need to put "pythonw" in my #! lines, which may fail on other *nix systems, and... One thought is to simply have "python" be the same shell script as "pythonw" but there is concern that having it be a re-directing shell script may cause problems for some use cases. I know that this has been solved for years in the python.org installer. So how is that done? Anaconda doesn't seem to want to make their python a proper framework build -- don't know why not -- would there be any downside? But is it possible to build the python executable so it can access the GUI system without structuring their whole python install? Thanks, -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: From nad at acm.org Fri Aug 22 23:48:49 2014 From: nad at acm.org (Ned Deily) Date: Fri, 22 Aug 2014 14:48:49 -0700 Subject: [Pythonmac-SIG] What does it take to run a GUI app? References: Message-ID: In article , Chris Barker wrote: > Over on the list for the Anaconda distribution, we've run into a limitation > in our understanding of the whole app bundle, etc business. > > The problem is thus: > > Anaconda is currently built with the old python / pythonw dichotomy. On vanilla OS X python builds, there is no difference between python and pythonw; that's been the case going back many years. pythonw* files are/were just symlinks to the correspoing python* files. In fact, as of 3.4, we no longer make the pythonw* symlinks. > python is a standard unix-style executable -- great for command line apps, > web servers, what have you. But you get the dreaded: > > """ > This program needs access to the screen. > Please run with a Framework build of python, and only when you are > logged in on the main display of your Mac. > """ > > when you try to run a GUI app (this error message from wxPython) > > pythonw, on the other hand, is a shell script that re-directs to a python > that is inside a hand-built application bundle: > > #!/bin/bash > export > PYTHONEXECUTABLE=/Users/chris.barker/PythonStuff/Anaconda/anaconda/bin/python > /Users/chris.barker/PythonStuff/Anaconda/anaconda/python.app/Contents/MacOS/py > thon > $@ This is something supplied by Anaconda? > This all sort-of works. But it's a pain, because you may not know when you > start up an app, whether it needs to access the Window manger (like > iPython, for instance). And now I need to put "pythonw" in my #! lines, > which may fail on other *nix systems, and... > > One thought is to simply have "python" be the same shell script as > "pythonw" but there is concern that having it be a re-directing shell > script may cause problems for some use cases. > > I know that this has been solved for years in the python.org installer. So > how is that done? A framework build, like used in the python.org installer, creates a Python.app app bundle within the framework: /Library/Frameworks/Python.framework/Versions/x.y/Resources/Python.app and the real Python executable is located there, in ./Contents/MacOS/Python like a standard OS X app. The tricky part is that a bootstrap executable, built from the somewhat confusingly named pythonw.c (http://hg.python.org/cpython/file/3.4/Mac/Tools/pythonw.c), is what is actually installed into the framework bin directory and symlinked to from /usr/local/bin/ or wherever. The bootstrap executable's job is to essentially transparently launch Python.app from the command line. That is, when you type: /usr/local/bin/pythonx.x or /Library/Frameworks/Python.framework/Versions/3.4/bin/pythonx.y you are first executing the bootstrap executable and it then spawns or execs the real interpreter executable under Python.app so that Python runs as a app that can be a gui process. Now, these days, most of the time you probably don't need to be a gui process, especially since we no longer support the obsolete deprecated Mac Carbon-based API wrapper functions in the standard library. And if you are building you own gui app, presumably you can use py2app to produce your app as its own app bundle. I'm not familiar with wxPython at all but, if it doesn't already, it might be able to take the approach Tcl/Tk does on OS X. Tk seems to do some tricks to make itself a gui process and it also has an embedded Wish.app at least when Tk is built as a framework. But I haven't looked closely at it. The relevant code in the the Tk file macosx/tkMacOSXInit.c. > Anaconda doesn't seem to want to make their python a proper framework build > -- don't know why not -- would there be any downside? But is it possible to > build the python executable so it can access the GUI system without > structuring their whole python install? One issue might be that the current framework builds are meant to be installed at a fixed path, by default /Library/Frameworks. You can change that at build time but we don't support changing it at install or run time. Without knowing more, I'd look to solving the issue in wx rather than Python since it might affect other users as well. The Python framework GUI stuff is quite old and hasn't really been closely examined in a long time. There *might* be better ways to do it today. -- Ned Deily, nad at acm.org From chris.barker at noaa.gov Sat Aug 23 03:31:19 2014 From: chris.barker at noaa.gov (Chris Barker) Date: Fri, 22 Aug 2014 18:31:19 -0700 Subject: [Pythonmac-SIG] What does it take to run a GUI app? In-Reply-To: References: Message-ID: On Fri, Aug 22, 2014 at 2:04 PM, Aaron Meurer wrote: > It does cause problems. I'm not entirely clear what happens with > nested shebang lines, but you can't put > > #!/Users/aaronmeurer/anaconda/bin/pythonw > > as your shebang. If you do, it will try to run the script in bash. It has > to be > > #!/bin/bash /Users/aaronmeurer/anaconda/bin/pythonw > > OK, then this is broken anyway for scripts that need a GUI and want to use a #! line to start.....so another solution really would be good. > A (possibly weak) argument for not wanting to do a full framework > build is that it would break backwards compatibility with file > locations (possibly weak because the right symlinks might make > everything work). I believe the real reason is that it's (as far as > we can tell) unnecessary complexity, especially given that the fake > app bundle seems to work just as well. > for this, perhaps. But it's not all all complex, and might actually solve antoher problem (OK, my other problem) of keeping the python libs separated from all the other Anaconda libs... -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.barker at noaa.gov Sat Aug 23 03:48:36 2014 From: chris.barker at noaa.gov (Chris Barker) Date: Fri, 22 Aug 2014 18:48:36 -0700 Subject: [Pythonmac-SIG] What does it take to run a GUI app? In-Reply-To: References: Message-ID: Thank Ned, > Anaconda is currently built with the old python / pythonw dichotomy. > > On vanilla OS X python builds, there is no difference between python and > pythonw; that's been the case going back many years. exactly -- I was quite surprised when i ran into this with Anaconda -- I had totally forgotten about pythonw -- and the goal is to let us all continue to forget about it. > In fact, as of > 3.4, we no longer make the pythonw* symlinks. > Another reason why we really don't want to use that... > pythonw, on the other hand, is a shell script that re-directs to a python > that is inside a hand-built application bundle: > > #!/bin/bash > export > PYTHONEXECUTABLE=/Users/chris.barker/PythonStuff/Anaconda/anaconda/bin/python > /Users/chris.barker/PythonStuff/Anaconda/anaconda/python.app/Contents/MacOS/py > thon > $@ This is something supplied by Anaconda? > yup. > > I know that this has been solved for years in the python.org installer. > So > > how is that done? > > > A framework build, like used in the python.org installer, creates a > Python.app app bundle within the framework: > > /Library/Frameworks/Python.framework/Versions/x.y/Resources/Python.app > > OK -- this is more or less what Anaconda does, though without the whole Framework, just the app bundle. > The tricky part is > that a bootstrap executable, built from the somewhat confusingly named > pythonw.c (http://hg.python.org/cpython/file/3.4/Mac/Tools/pythonw.c), > is what is actually installed into the framework bin directory and > symlinked to from /usr/local/bin/ or wherever. The bootstrap > executable's job is to essentially transparently launch Python.app from > the command line. ah hah! that is what Anaconda's pythonw script does, but not as well. This is what we've been looking for. > That is, when you type: > > /usr/local/bin/pythonx.x > or > /Library/Frameworks/Python.framework/Versions/3.4/bin/pythonx.y > > you are first executing the bootstrap executable and it then spawns or > execs the real interpreter executable under Python.app so that Python > runs as a app that can be a gui process. > Is there any downside to this? a measurable amount of overhead? > Now, these days, most of the time you probably don't need to be a gui > process, especially since we no longer support the obsolete deprecated > Mac Carbon-based API wrapper functions in the standard library. And if > you are building you own gui app, presumably you can use py2app to > produce your app as its own app bundle. > you can. but you sure don't want to from the start of your development process. And there are hybrid command-line GuI apps like iPython or anything that wants to pop up, say, a matplotlib graph. So we do need a command line python that can run a GUI. > I'm not familiar with wxPython at all but, if it doesn't already, it > might be able to take the approach Tcl/Tk does on OS X. Tk seems to do > some tricks to make itself a gui process and it also has an embedded > Wish.app at least when Tk is built as a framework. But I haven't looked > closely at it. The relevant code in the the Tk file > macosx/tkMacOSXInit.c. > > well, _maybe_ the alpha wx project, "Phoenix" could do this, but the legacy version will be around for a while. And it looks like folks are having problems with native Cocoa GUIs as well (at least with matplotlib, that I know of) > > Anaconda doesn't seem to want to make their python a proper framework > build > > -- don't know why not -- would there be any downside? But is it possible > to > > build the python executable so it can access the GUI system without > > structuring their whole python install? > > One issue might be that the current framework builds are meant to be > installed at a fixed path, by default /Library/Frameworks. You can > change that at build time but we don't support changing it at install or > run time. > well Anaconda would need to be able to re-locate, that's kind of the point -- so probably why they didn't just grab that build to begin with. Not that they couldn't make a re-locatable Framework. But problem at hand is about the app bundle and start up executable, not the Framework anyway. Without knowing more, I'd look to solving the issue in wx rather than > Python since it might affect other users as well. well, this isn't jsut a wx problem. IT seems beter to me to solve it at teh python level, rather than the separate GUI level. > The Python framework > GUI stuff is quite old and hasn't really been closely examined in a long > time. There *might* be better ways to do it today. > There might -- but if it ain't broke.... thanks for pointing us to the relevant code -- if the Anaconda folks want to fix this, that looks like a good place to start. Or if anyone has any ideas for a better way... Maybe whatever tk does to trick the system? Thanks again, -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.barker at noaa.gov Wed Aug 27 18:54:37 2014 From: chris.barker at noaa.gov (Chris Barker) Date: Wed, 27 Aug 2014 09:54:37 -0700 Subject: [Pythonmac-SIG] What does it take to run a GUI app? In-Reply-To: References: Message-ID: On Mon, Aug 25, 2014 at 8:32 AM, Aaron Meurer wrote: > > you can. but you sure don't want to from the start of your development > > process. And there are hybrid command-line GuI apps like iPython or > anything > > that wants to pop up, say, a matplotlib graph. So we do need a command > line > > python that can run a GUI. > > Yes, matplotlib is big here. The default backend on OS X uses a Cocoa > GUI, which is almost completely broken if not run with a framework > build (see https://github.com/matplotlib/matplotlib/issues/665). > > However, I just tested both Anaconda pythonw and the python.org python > (both 3.4), and neither work directly with matplotlib. Both require > you to start IPython and type %matplotlib or the plot will not show. That's standard iPython -- it has to do with event loops capturing (or not) the REPL. Nothing to so with the issue at hand. YOu can also start up iPython with this turned on (ipython --pylab, I think) > well Anaconda would need to be able to re-locate, that's kind of the point > > -- so probably why they didn't just grab that build to begin with. Not > that > > they couldn't make a re-locatable Framework. But problem at hand is about > > the app bundle and start up executable, not the Framework anyway. > > Yes, relocatability is essential. Conda can make path replacements in > plain text files at install time, but in general it's best if > everything uses relative paths. hence the avoidance of a Framework -- though _maybe_ one could build a re-locatable framework. > The app bundle seems to work just as well as the framework. If > something explicitly looks for WITH_NEXT_FRAMEWORK it fill fail > (although we could probably forcibly set that to 1 if it helps). yup -- these are orthogonal -- for the GUI issue you need the app bundle. So the trick at hand is how to re-direct an executable in a "normal" location to the one in the app bundle. While Ned may be right that there could be a better way to do it, the short bit of code (pythonw.c) in the python source has been working well for years -- seem worth giving it a shot with Anaconda. As for a Framework build, one advantage it would give is keeping the python lib dir cleanly separated from the rest of the Anaconda lib dir (this has caused problems for me, anyway). There are other ways to do that anyway, if you choose to do so. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: