Jack et al, Yes, lots of deja vu here as well -- I suppose because this hasn't been resolved.
> Hmm, that was a long sentence for what was intended to be the question: “What is the problem with using a normal MacOS Framework build of Python for Anaconda”? I can't really answer this -- I was not part of the original discussion, nor am I in an decision making position now. I'm just a user an contributor to conda-forge that's trying to make things easier. But I think it more or less comes down to what you said: Conda wants to be as similar as possible on all platforms as it can. Yes, there are differences on Windows, but they are keeping those to a minimum, and there is no choice. OS-X, on the other is, as you mentioned, BSD *nix. So doing something very differently there feels gratuitous. And in a practical sense, many folks use OS-X as a development platform, so want to use Python on OS-X in the same way they use it on other *nix systems. I myself have found this to be very helpful for my own work, as well as for teaching. And if you aren't doing any GUI work, then it is nice for the Mad to be "just another *nix". For my part, I develop for the MAc, but only in the context of cross platform tools: I never do anything you can do only on the Mac, and try to do everything in a cross platform way as possible (using wPyrthon for the GUI, for instance). Which is why I want Python, and everything else to work the same . That being said, I'm not sure that this was thought through all that carefully initially, and I haven't seen anyone spell out the reasons for not doing a Framework build other than "Honestly, I think adding the framework will make this more confusing when building things between OS X and Linux" (from https://github.com/conda-forge/python-feedstock/issues/23). But I'll turn around the question: "What is the problem with using a non-framework build for conda on the Mac" (or even outside of conda, e.g.brew or macports) It's unclear to me is what the advantages of a Framework Build are in this context. Other than it being the "Mac way of doing things". It's my impression that Apple simply has not thought out how it should support things like Python -- the whole system is very much designed around "Applications", but the Python interpreter is not an application in the usual sense. But it is also not a library in the usual sense, either. So I'm not sure there IS an obvious right way to support Python on a a Mac. And I understand the idea behind frameworks, and like them. I've never much liked the scattering of things all over the filesystem approach that *nix usually does. But in this case, conda is doing a similar thing, but in a more powerful and flexible way. So cramming a Framework into conda seems gratuitous. As far as I know, the only issue people have had with using a standard Unix build in conda is the whole GUI thing.Jack mentioned a lot of others, essentially interacting the the non-kernel part of the OS, but I haven't heard complaints about that -- maybe because no one's doing that with conda. But the key technical question I'm still not totally clear on is: I understand (vaguely) what having Python running from a App bundle provides -- and these are important features, so we do want to support that. And I I thought that the executable re-directs to one in a bundle could be done independently of the Framework, and the fact that the two is essentially and accident of how they build scripts were set up (and probably easier to do). If I'm correct, then Python could be built to provide an app bundle, but otherwise be just like a "normal" unix build. But what does having Python built as a Framework actually provide, other than making more like the usual Mac setup? As far as I can tell, it would provide no new functionality. In which case, given a choice, for, e.g. a conda build, I'd rather have it be more like the other *nixes than more like other Mac software. In short: as far as I can tell, the only reason to use a Framework build in conda is that it's the only configuration that's already set up to make pythonw in the build scripts, and autoconf is enough of a pain that one wants to make a new configuration. By the way, I chatted with Ned Diely a few years ago about this, and I think he was thinking of moving away form Frameworks for python.org builds, though I don't know if he decided not to make that change, or simply hasn't gotten around to it. -CHB References to Discussions: https://github.com/conda-forge/python-feedstock/issues/23 > Jack > > On 14-Mar-2020, at 14:54 , Ronald Oussoren <ronaldousso...@mac.com> > wrote: > > > > On 13 Mar 2020, at 20:36, Christopher Barker <python...@gmail.com> wrote: > > There is a private API that makes it possible to use GUI libraries outside >> of an app bundle and that’s used by a number of projects, but I wouldn’t >> want to use that in Python. >> > > Is that what TK is doing? > > > I don’t know. > > > And while probably not good to build it into Python itself, what about > building into the GUI toolkits? > > Do you have a reference to that API? > > > I don’t have a reference handy, it has come up before either on this list > or the python tracker (years back). IIRC someone found the API by checking > how the bundled java VM managed to use GUI APIs without being in an app > bundle. > > Apple is clearly preferring application code packaged as app bundles, and > effectively doesn’t care about traditional Unix-y use of macOS. The need > for an app bundle when using frameworks is just one example of that. > Another example are the issues that keep popping up when trying to use > Apple frameworks in child processes after calling os.fork(). > > Because of this I don’t think it is worthwhile to try to work around this > limitation by calling private APIs. That’s even before considering use > cases that involve distributing code through the macOS app store. > > Ronald > — > > Twitter: @ronaldoussoren > Blog: https://blog.ronaldoussoren.net/ > > > -- > > Jack Jansen, <jack.jan...@cwi.nl>, http://www.cwi.nl/~jack > > If I can't dance I don't want to be part of your revolution -- Emma Goldman > > > > -- 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
