Thanks for your thoughts, guys. Now I'm more confused about what is best to do:
On Wed, Mar 11, 2020 at 2:44 PM Jack Jansen <jack.jan...@cwi.nl> wrote: > As the person who originally invented (or co-invented? Not quite sure > anymore) Well, I'll give y9ou credit, you pretty much single handedlhy kept Python alive on the Mac for along time! - There are now perfectly sane ways to build bundles (whether Framework or > App bundles) using the Apple command line tools. So if there’s still any of > the old cruft around it should go out the window. > can they build a weird-ass looks like an executable, but it's in a app bundle like we have now? Anyway, nice to know there are better tools out there. > - I _think_ that the restriction that a GUI program must be in an App > bundle no longer holds, Well, it still doesn't "just work" or at least there are ways around it. That may be the case -- I'm a bit unsure now, but that reminded me to check: Tkinter seems to work on a conda build (standard Unix build) without pythonw or python.app. So it is possible. I guess the GUI toolkit is doing something. If anyone knoes what that is, then we can maybe solve this at the GUI toolkit level, there are only a small handfull of them (TK(done), wx, qt, pyObjC (Ronald, does that work without the pythonw hack?)) -- but some fraily quick Googling is not helping me figure this out. > There are all sorts of programs installed with brew that present a GUI > without being in an app bundle. I’m looking at realsense-viewer right now, > as an example, and it’s a normal executable in > /usr/local/Cellar/librealsense/2.22.0/bin/realsense-viewer with a symlink > in /usr/local/bin. > what is it using for GUI? > - But: this still doesn’t bring the OSX builds in line with “normal” unix > builds. To do that Python would have to do away with Frameworks and go move > to a normal dylib/so/dll structure. well, for conda, we're using a plain old *nix build, and as far as I can see, this is the only issue. That would seem very unwise, especially nowadays as Apple is moving more > and more towards having everything that you want to install be signed and > notarized and whatnot. I wouldn’t be surprised at all if some time soon > “free dylibs”, i.e. dylibs outside of an app bundle or framework bundle, > become impossible unless you build them yourself from source. > I hope not -- that would be a nightmare for us folks that wants to use the Mac as a development / data analysis / anything-but-point-and-clicky-app-running platform. It's kind of funny, Apple managed to wrap a nice GUI around *nix in such a way that both user groups could be happy. But they are making it harder and harder for the geeks :-). I suppose it's a small part of their market, but in my circles, most people use the Mac as *nIx with a nice GUI, and the *nix part is critical. On Wed, Mar 11, 2020 at 7:58 AM Ronald Oussoren <ronaldousso...@mac.com> wrote: > I’m not very active at the moment, but… framework builds and in > particular the embedded Python.app are necessary to be able to use GUI > libraries on macOS in scripts. > exactly, but the Framework part is orthogonal to the Python.app part -- I'm looking for the app thing without the Framework. Though maybe it's not required anymore (see Jack's comments). The alternative is that users always use py2app/pyinstaller/… to build an > .app bundle themselves. > Exactly -- but that is a pain for development, and means making a GUI app is very diferent on OS-X than other systems, it doesn't play well with setuptools entry points, etc.... A side-effect of having a Python.framework is that this makes integration > with Xcode slightly easier, but that’s a secondary concern. We primarily > used a framework because that was the modern platform way of packaging > libraries with supporting files (instead of sprinkling everything into > /usr/local). > Sure. But conda, at least, provides an alternative to manage all that that works the same on all platforms. So within conda, it's nice to have a regular old *nix style build. > > So you are not using a regular installation… In a regular framework build > $prefix/bin/python and …/pythonw is a small executable that launches the > python executable in the embedded Python.app > exactly -- we are using a "regular" *nix build, NOT the framework build, or anything Mac specific. The problem is that we do want the pythonw trick, but not the whoile Framework. What’s wrong with using a framework install? It makes it totally different than all teh other conda environments (Linux, Windows, etc) And conda manages al sorts of other stuff, notably unix libraries and the like, that have to work with Python. It's not out of the quwestion to use a Framework in conda, but it would buy us nothing, and be a pain. And the only reason to do it would be to get the pythonw functionaility. > That makes 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
