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 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. Just On Thu, 12 Mar 2020, 01:11 Christopher Barker <python...@gmail.com> wrote: > 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 >
_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
