[Pythonmac-SIG] Building plans .....

Sat Mar 14 18:49:05 EDT 2020

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 <ronaldoussoren at mac.com>
> wrote:
>
>
>
> On 13 Mar 2020, at 20:36, Christopher Barker <pythonchb at 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.Jansen at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20200314/bf5f1907/attachment-0001.html>