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

[Christopher Barker]

> Does this force the use of conda on macOS python users?

Absolutely not.


> Or is it just asking for a build option that is conda friendly?
>

That’s it exactly. I would think it would be friendly to other use cases,
but the default Python.org builds are a different use case, and should be
built in a way that’s appropriate for those users.

I have been happy use the python.org builds and py2app + PyQt5.
>

Exactly— I’m not suggesting anything change for folks like you.

-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

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

[Barry Scott]

> On 16 Mar 2020, at 22:54, Jack Jansen  wrote:
> 
> 
>> 
>> but "conda" is a package management tool, a bit like yum or apt in the Linux 
>> world, or Brew, for that matter. except that:
>> 
>> * It is platform independent -- it attempts to work the same way on all all 
>> platforms to the degree possible.
>> * It provides management of isolated "environments", so you can have a 
>> different collection of software and libraries, all with a different 
>> combination of version on the same system, isolated from one another.
> 
> 
> So how does conda handle things that must be installed in “special” locations 
> on some platforms? For example, if you install some package that contains a 
> kernel driver, undoubtedly on windows this’ll have to go somewhere deep down 
> in c:\system32 or something.

Does this force the use of conda on macOS python users?

Or is it just asking for a build option that is conda friendly?

I have been happy use the python.org  builds and py2app + 
PyQt5.

Barry



> 
> Because in a way Python on the mac (if you want to use a framework/app/bundle 
> Python) is like that: it has some platform-specific installation requirements 
> (that bits of it go into /Library/Frameworks and other bits in /Application), 
> and in the end you setup a few symlinks in the conda bin directory (or the 
> conda per-environment bin directory, or however that works) and for a conda 
> user the situation will be exactly the same on Mac as on Linux…..
> --
> Jack Jansen, mailto: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
> 
> 
> 
> ___
> 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

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

[Christopher Barker]

On Mon, Mar 16, 2020 at 3:55 PM Jack Jansen  wrote:

but "conda" is a package management tool, a bit like yum or apt in the
Linux world, or Brew, for that matter. except that:

* It provides management of isolated "environments", so you can have a
different collection of software and libraries, all with a different
combination of version on the same system, isolated from one another.

So how does conda handle things that must be installed in “special”
> locations on some platforms? For example, if you install some package that
> contains a kernel driver, undoubtedly on windows this’ll have to go
> somewhere deep down in c:\system32 or something.
>

I expect that answer is "it doesn't" -- it's really not intended to support
things like kernel drivers. The point of conda is not just package
management, but  the ability to create isolated environments, with specific
versions of various inter-dependent packages.

An environment is essentially a directory tree with a loto f familiar (to
the *nix folks, anyway) directories. Here's what's in my primary working
environment, for example:
$ ls
binphrasebooks
conda-meta plugins
docqml
etcqsci
includeresources
libsbin
libexecshare
manssl
mkspecstranslations

When you "activate" an environment, it sets up a bunch of environment
variables so that those "Versions" are found first. Here's $PATH by my
primarily working environment (called py3) is activated:

$ echo $PATH
/Users/chris.barker/miniconda3/envs/py3/bin:/Library/TeX/texbin:/Users/chris.barker/miniconda3/condabin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/sbin

It prepended the bin dir from the Environment on there. It does similar
things to all the other env variables.

Because in a way Python on the mac (if you want to use a
> framework/app/bundle Python) is like that: it has some platform-specific
> installation requirements (that bits of it go into /Library/Frameworks and
> other bits in /Application), and in the end you setup a few symlinks in the
> conda bin directory (or the conda per-environment bin directory, or however
> that works) and for a conda user the situation will be exactly the same on
> Mac as on Linux…..
>

So yes, you could install the entire Framework inside the environment, and
then have the various links to the "expected" places inside that
environment (conda uses relative paths wherever possible, so it wouldn't be
hard). And probably, it would end up looking just like a *nux install as
far as everything else is concerned, except for that extra Framework thing
in there somewhere that could be ignored.

I'm not sure why the conda folks decided not to do that in the first place,
but they didn't, and no one seems to want to do it now.

I suppose I could set it up and submit a PR and see what folks think, but
the big question is: what does a Framework Build by conda? ANd I think the
answer is nothing, except that we already know how to build the pythonw
executable that way.

-Chris
-- 
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

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

[Jack Jansen]

> 
> but "conda" is a package management tool, a bit like yum or apt in the Linux 
> world, or Brew, for that matter. except that:
> 
> * It is platform independent -- it attempts to work the same way on all all 
> platforms to the degree possible.
> * It provides management of isolated "environments", so you can have a 
> different collection of software and libraries, all with a different 
> combination of version on the same system, isolated from one another.


So how does conda handle things that must be installed in “special” locations 
on some platforms? For example, if you install some package that contains a 
kernel driver, undoubtedly on windows this’ll have to go somewhere deep down in 
c:\system32 or something.

Because in a way Python on the mac (if you want to use a framework/app/bundle 
Python) is like that: it has some platform-specific installation requirements 
(that bits of it go into /Library/Frameworks and other bits in /Application), 
and in the end you setup a few symlinks in the conda bin directory (or the 
conda per-environment bin directory, or however that works) and for a conda 
user the situation will be exactly the same on Mac as on Linux…..
--
Jack Jansen, , http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman



___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

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

[Christopher Barker]

On Mon, Mar 16, 2020 at 1:09 AM Georg Seifert  wrote:

> > - A framework build is easier to integrate into applications that are
> built using Xcode (just drop the framework into list of used frameworks)
> > When would that come into play? If you are developing an application
> that embeds the python interpreter? OR if you are using XCode as your IDE
> for developing a Python App?
> >
> I’m using that in my app (written in ObjectiveC) to be able to run python
> scripts inside the app and to load plugins that are written in python but
> don’t bring there own python interpreter.
>

Perfect -- and that's using Python more as a "library". So providing a
Framework build is a good thing for these uses. Though I wonder if there's
a need for a pre-built one with an installer --wouldn't folks using XCode
be able to built it themselves? But either way, this isn't a use case for
conda, or brew or 

Also, there's no reason that a "PythonFramework" couldn't be a
separate package in conda -- you just wouldn't want to have all the other
Python-y stuff depending on it. If you are embedding the interpreter, you
are managing all the the dependencies anyway.

Now someone just needs the time to do it :-(

-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

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

[Ronald Oussoren via Pythonmac-SIG]

> On 15 Mar 2020, at 22:04, Christopher Barker  wrote:
> 
> On Sun, Mar 15, 2020 at 4:39 AM Ronald Oussoren  > wrote:
> AFAIK the only difference for this discussion is the “Python.app” trick, and 
> that can be accomplished outside of a framework build as well (but currently 
> is not). 
> 
> Two other differences:
> - A framework build is easier to integrate into applications that are built 
> using Xcode (just drop the framework into list of used frameworks)
> When would that come into play? If you are developing an application that 
> embeds the python interpreter? OR if you are using XCode as your IDE for 
> developing a Python App?

That’s something you can use to embed Python into an ObjC app. 

>  
> - py2app currently doesn’t work properly with a Unix build
> 
> But that could be fixed, yes? (And I think PyInstaller already does work with 
> a unix build)

Sure. Fixing this isn’t too hard, although it will take more time than I’d like 
due to the way the code is structured. 

> 
> I *think* this means that a unix-style build with the python.app "trick" 
> would be appropriate for use in distributions that are otherwise not "mac 
> native" -- e.g. conda, homebrew.
> 
> As to whether a style build would be OK for the python.org 
>  installer, I'm not so sure. That may still be a 
> candidate for a Framework build --it sure does make installation/uninstalling 
> easier than scatter files all over /usr/local.

Right. That’s an important consideration given that macOS doesn’t have a proper 
native package manager, just an installer.

> 
> Of course, to make any of this happen, someone with the autoconf skills needs 
> to have the time and motivation to do it. I'm not that person (though who 
> knows how far I would have gotten if I'd spent the time I've spent talking 
> about this actually giving it a try :-) )
> 
> So we'll see. Maybe there's no one that both wants this done and has the time 
> and skills to do it -- such is the world of open source.

Agreed. In the end everyone working on Python is a volunteer.

Ronald

—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

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

[Georg Seifert]

> On 15.03.2020, at 22:04, Christopher Barker  wrote:
> 
> On Sun, Mar 15, 2020 at 4:39 AM Ronald Oussoren  
> wrote:
> AFAIK the only difference for this discussion is the “Python.app” trick, and 
> that can be accomplished outside of a framework build as well (but currently 
> is not). 
> 
> Two other differences:
> - A framework build is easier to integrate into applications that are built 
> using Xcode (just drop the framework into list of used frameworks)
> When would that come into play? If you are developing an application that 
> embeds the python interpreter? OR if you are using XCode as your IDE for 
> developing a Python App?
>  
I’m using that in my app (written in ObjectiveC) to be able to run python 
scripts inside the app and to load plugins that are written in python but don’t 
bring there own python interpreter.

Best
Georg Seifert

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

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

[Christopher Barker]

On Sun, Mar 15, 2020 at 4:39 AM Ronald Oussoren 
wrote:

> AFAIK the only difference for this discussion is the “Python.app” trick,
> and that can be accomplished outside of a framework build as well (but
> currently is not).
>
> Two other differences:
> - A framework build is easier to integrate into applications that are
> built using Xcode (just drop the framework into list of used frameworks)
>
When would that come into play? If you are developing an application that
embeds the python interpreter? OR if you are using XCode as your IDE for
developing a Python App?


> - py2app currently doesn’t work properly with a Unix build
>

But that could be fixed, yes? (And I think PyInstaller already does work
with a unix build)

I *think* this means that a unix-style build with the python.app "trick"
would be appropriate for use in distributions that are otherwise not "mac
native" -- e.g. conda, homebrew.

As to whether a style build would be OK for the python.org installer, I'm
not so sure. That may still be a candidate for a Framework build --it sure
does make installation/uninstalling easier than scatter files all over
/usr/local.

Of course, to make any of this happen, someone with the autoconf skills
needs to have the time and motivation to do it. I'm not that person (though
who knows how far I would have gotten if I'd spent the time I've spent
talking about this actually giving it a try :-) )

So we'll see. Maybe there's no one that both wants this done and has the
time and skills to do it -- such is the world of open source.

-CHB




> Ronald
>
> —
>
> Twitter: @ronaldoussoren
> Blog: https://blog.ronaldoussoren.net/



-- 
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

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

[Ronald Oussoren via Pythonmac-SIG]

> On 15 Mar 2020, at 03:11, Christopher Barker  wrote:
> 
> Thanks Jack.
> 
> But I'm still confused about a technical question:
> 
> Does having python itself in a Framework enable anything that having it 
> outside a Framework won't let you do?

AFAIK the only difference for this discussion is the “Python.app” trick, and 
that can be accomplished outside of a framework build as well (but currently is 
not). 

Two other differences:
- A framework build is easier to integratie into applications that are built 
using Xcode (just drop the framework into list of used frameworks)
- py2app currently doesn’t work properly with a Unix build

Ronald

—

Twitter: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

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

[Christopher Barker]

Thanks Jack.

But I'm still confused about a technical question:

Does having python itself in a Framework enable anything that having it
outside a Framework won't let you do?

This is completely aside from the python in an app bundle question, as you
can certainly have a python binary with no app bundle, and you can have
python in an app bundle with no Framework (indeed, the current conda Python
python.app hack works with an otherwise standard Unix build). Again, I'm
curious what a Framework buys you (or anyone). ANd I'm not talking bout the
"framework build" that is currently provided by the python.org build
scripts, but a Framework in the general sense.

Second: the whole intertwining of conda, Anaconda, brew, etc, is very
confusing, so I'll try to provide a bit of clarity here:

I think we all know what brew (and macports, if anything is still using
that) is.

but "conda" is a package management tool, a bit like yum or apt in the
Linux world, or Brew, for that matter. except that:

* It is platform independent -- it attempts to work the same way on all all
platforms to the degree possible.
* It provides management of isolated "environments", so you can have a
different collection of software and libraries, all with a different
combination of version on the same system, isolated from one another.

* critically, it can manage, in theory, ANY software or library --
including Python, of course.
* conda is written in Python, but otherwise but is not specifically about
Python.
* In practice, it is currently used mostly for Python and associated
libraries, but also R, node.js, geospatial libraries and tools, etc.

"Anaconda" is a particular "distribution" of Python and data science
software that is curated with a bunch of packages that are all tested and
work together. It also comes with nifty GUI tools to manage the packages,
etc.

Importantly, conda the package manager, can be, and is, used to manage
collections of software without Anaconda (see "miniconda)

In theory, anyone could build and distribute conda packages in any way (or
build then themselves and entirely self manage them). In practice, THe
anaconda.org site is used as a repository of packages. Anyone can set up
their own "channel" and distribute whatever they want.

In addition to the packages being distributed by the Anaconda company, and
a whole variety of private channels on anaconda.org, there is the
"conda-forge" project, which is a community-driven curated collection of a
packages available on anaconda.org, and managed by a big ol' gitHub org.

Now that that's done:

On Sat, Mar 14, 2020 at 4:41 PM Jack Jansen  wrote:

> I think you have to decide who the target audience is, and based on the
> needs of the target audience decide. Possibly deciding to go both ways.
>

I agree -- there are different needs for different audiences, and there may
not be one single way to build Python that meats all needs.


> One target audience is Unix developers who happen to use a Mac because
> it’s a convenient Unix development platform (and, practically speaking, the
> only viable BSD development platform left nowadays). These will use brew,
> build things from source, and they’ll be perfectly happy with a
> non-framework build. And if they ever need to use a library that requires
> to be in a framework you teach them to use some magic command to do that
> (tell them to please try `MagicMacPythonWrapper pip install foo` if `pip
> install foo` doesn’t work, that kind of thing).
>

I think that audience is currently satisfied by the regular old *nix builds
(though I think Brew actually does Framework builds, oddly enough -- but I
haven't used brew in a while, since I discovered conda). Though many of
these users would be well served by conda as well, with a stndard *nix
build.

Another target audience is Mac users, with some limited programming needs.
> Think artists, designers, musicians, etc. These will use Python to connect
> strange and wondrous hardware to strange and wondrous software packages,
> and they will definitely need a framework build because otherwise it won’t
> interface to their funny hardware, and they won’t know how to get through
> all the dialogs that say you can’t install this because it isn’t trusted or
> it won’t load this DLL because it is untrusted or yadda yadda yadda.
>

I'm still unclear on that -- do they really need a Framework build? or do
they only need the executable to be in a app bundle? And the current
Framework builds, I think, satisfy these users pretty well.

And a third audience is scientists who are not developers, or at least not
> primarily developers, and who don’t have a strong attachment to either Mac
> or Unix.
>

That's pretty much the audience I'm concerned with now -- and tha one that
is not quite well served at the moment. (though some may well be attached
to the Mac, but aren't writing code specifically for the Mac )


> Here I don’t mean people who don’t develop at all (because then they
> wouldn’t need 

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

[Jack Jansen]

I was tempted to answer this point-by-point, but I think that would lead to a 
discussion that’ll quickly branch into many different ways and won’t lead to 
anything.

I think you have to decide who the target audience is, and based on the needs 
of the target audience decide. Possibly deciding to go both ways.

One target audience is Unix developers who happen to use a Mac because it’s a 
convenient Unix development platform (and, practically speaking, the only 
viable BSD development platform left nowadays). These will use brew, build 
things from source, and they’ll be perfectly happy with a non-framework build. 
And if they ever need to use a library that requires to be in a framework you 
teach them to use some magic command to do that (tell them to please try 
`MagicMacPythonWrapper pip install foo` if `pip install foo` doesn’t work, that 
kind of thing).

Another target audience is Mac users, with some limited programming needs. 
Think artists, designers, musicians, etc. These will use Python to connect 
strange and wondrous hardware to strange and wondrous software packages, and 
they will definitely need a framework build because otherwise it won’t 
interface to their funny hardware, and they won’t know how to get through all 
the dialogs that say you can’t install this because it isn’t trusted or it 
won’t load this DLL because it is untrusted or yadda yadda yadda.
 
And a third audience is scientists who are not developers, or at least not 
primarily developers, and who don’t have a strong attachment to either Mac or 
Unix. Here I don’t mean people who don’t develop at all (because then they 
wouldn’t need Anaconda) but who are basically data scientists or deep learning 
people or whatever, and who have been told that there’s a nifty package in 
Python that’ll do just what they need. And for them I think you need to look at 
how Anaconda treats the difference between Windows and Linux: if it tries to 
hide that difference as much as possible (like jupyter does, for example, but 
also completely different things like Adobe CS which really tries to make their 
software look that same independent of platform) you should do the same.

And if you can’t decide: how much work would it be to have two Anaconda 
distributions for the Mac: 
- one that is primarily Unix-y, installed through brew, intended to be used 
from the command line, and with the MagicMacPythonWrapper
- another one that is framework-based, installed as an app bundle, signed, 
notarized, all that jazz, and comes with an “Anaconda Terminal” which is a 
perfectly normal Terminal but with all the environment and things setup so that 
people can use the command line in the Unix way but it would under the hood 
have all the PATH and DYLD_LIBRARY_PATH and whatnot to use the Python from the 
accompanying framework build always.

Jack


> On  14-Mar-2020, at 23:49 , Christopher Barker  wrote:
> 
> 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" 

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

[Christopher Barker]

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 
> wrote:
>
>
>
> On 13 Mar 2020, at 20:36, Christopher Barker  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 

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

[Jack Jansen]

I’m having an incredible amount of deja-vu in this conversation. We seem to be 
heading down the path of talking about little-documented APIs and such the same 
way we were doing 15 or 18 years ago….

Christopher,
can you explain what the problem is that you’re running into? Why is there a 
problem with the Mac Python builds having a different structure than other Unix 
Python builds? Windows Python builds also have a different structure, does the 
problem occur there as well?

From your original post it seems that the problems are with the 
Anaconda/Conda-forge distribution treating MacOS as “just another unix 
distribution”, with the idea that “Mac GUI compatibility” wouldn’t be too 
important for the Anaconda users, or could be handled with the pythonw 
workaround shellscript.

But actually “MacOS-compatible” would be a more accurate term here, because I’m 
pretty sure there are a whole lot of APIs that have nothing to do with the GUI 
but won’t work unless you’re running from a bundle: definitely Open Scripting, 
but probably also audio/video capture, probably anything using keychain like 
crypto serveices, maybe bluetooth, maybe USB, probably anything using the GPU 
for computations….. 

So basically if you build Python for MacOS as if it is “just another BSD 
distribution” then that is indeed what you get: a Python for just another BSD 
distribution.

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”?

Jack

> On  14-Mar-2020, at 14:54 , Ronald Oussoren  wrote:
> 
> 
> 
>> On 13 Mar 2020, at 20:36, Christopher Barker > > 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, , http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman



___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

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

[Ronald Oussoren via Pythonmac-SIG]

> On 13 Mar 2020, at 20:36, Christopher Barker  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/

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

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

[Christopher Barker]

>
> 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?

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?

-CHB


Ronald
> —
>
> Twitter: @ronaldoussoren
> Blog: https://blog.ronaldoussoren.net/
>
>
> --
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

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

[Ronald Oussoren via Pythonmac-SIG]

> On 11 Mar 2020, at 22:34, Jack Jansen  wrote:

[…]
> 
> - I _think_ that the restriction that a GUI program must be in an App bundle 
> no longer holds, or at least there are ways around it. 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. 

I’m not sure the limitation is really gone, I still see issues with a number of 
Cocoa APIs when run from a virtualenv environment, which doesn’t use the 
Python.app trick, while the same API works with a venv environement (which does 
use the Python.app trick). One example is 
>. 

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.

Ronald
—

Twitter: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/ 


___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

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

[Ronald Oussoren via Pythonmac-SIG]

> On 12 Mar 2020, at 07:48, Just van Rossum  wrote:
> 
> 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. 

That’s a limitation in the current version of py2app, but is something that 
could change if needed.

Ronald

—

Twitter: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

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

[Berg, Stuart]

(I haven’t been following this thread too closely, so sorry in advance if the 
following is not exactly what you’re looking for.)

FWIW, I’ve shipped .app bundles using conda and py2app for years.*  I don’t 
have time to write up a minimal example, but I can provide links to the scripts 
we use.

It’s a little bit of a hack, but it’s not complicated.


  1.  First, create a conda environment that contains your application and all 
of its dependencies.
  2.  Run py2app in “alias mode”[1]. Alias mode creates a mostly-empty bundle 
that merely links to an external python installation.  It’s intended for 
development, but we can exploit it for our purposes. On my project, we use a 
special setup.py script for this.[2]
  3.  Move the entire conda environment into the .app bundle directory.  
There’s no need to change the directory structure.
  4.  Since the .app bundle was pointing to that environment, you need to 
find/replace the internal links that py2app wrote within your .app bundle.  
Instead of pointing to the external conda environment, they should point to the 
now-internal environment (with relative paths, of course).  It amounts to a few 
sed commands and symlinks.[3]

Note: Although you moved the conda environment, there should (usually) be no 
need to replace any paths within the conda environment directory itself.  
Unless you’re doing something weird, most conda environments use purely 
relative links internally, and are thus fully relocatable.  For example, our 
application is based on the standard scientific python stack (numpy, pandas, 
skimage, etc.), with lots of other dependencies, too.  If it works for us, it 
probably works for most people.

If you want to see what the final bundle will look like, try downloading the 
current version of ilastik[4]. (Sorry, it’s a heavy download – it’s based on a 
big conda environment, with ~120 packages.)

Maybe there are better ways of doing this, but I settled on this method without 
really needing to understand exactly what py2app is really doing.  And plus, it 
leaves your conda environment completely intact.  For instance, you can inspect 
it with “conda list -p ilastik.app/Contents/ilastik-release”, or even install 
additional packages after-the-fact.

Best,
Stuart

*I don’t work on the ilastik project any more, but I’m pretty sure the current 
team still uses this procedure.

[1]: 
https://py2app.readthedocs.io/en/latest/tutorial.html#development-with-alias-mode
[2]: https://git.io/Jv6VG
[3]: https://git.io/Jv6Vl
[4]: https://www.ilastik.org/download.html



From: Pythonmac-SIG  
on behalf of Christopher Barker 
Date: Thursday, March 12, 2020 at 12:26 PM
To: Just van Rossum 
Cc: Jack Jansen , Pythonmac-Sig 
Subject: Re: [Pythonmac-SIG] Building plans .

On Wed, Mar 11, 2020 at 11:48 PM Just van Rossum 
mailto:justvanros...@gmail.com>> wrote:
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'm pretty sure it can. We've moved to PyInstaller, which does work, and 
I'm'pretty sure that py2app can work with conda's non-Framework build.

and it's on conda-forge, so presumably it's worked for at least one person :-)

https://anaconda.org/conda-forge/py2app<https://urldefense.com/v3/__https:/anaconda.org/conda-forge/py2app__;!!Eh6p8Q!VrzDuyXDlgxXw6SuvHF-vk_iAfL0Cl5PlPk5QD3NMR-hC7BhfmF-eaYhR_fDk6EgBQ$>

I do recall some issues a while back that have presumably been resolved.

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<https://urldefense.com/v3/__http:/python.org__;!!Eh6p8Q!VrzDuyXDlgxXw6SuvHF-vk_iAfL0Cl5PlPk5QD3NMR-hC7BhfmF-eaYhR_dlML8dSQ$>
 upon build. Which is wasteful, and in my eyes completely unnecessary.

https://github.com/actions/setup-python/issues/58<https://urldefense.com/v3/__https:/github.com/actions/setup-python/issues/58__;!!Eh6p8Q!VrzDuyXDlgxXw6SuvHF-vk_iAfL0Cl5PlPk5QD3NMR-hC7BhfmF-eaYhR_dcg4q17Q$>

I'm sad to learn conda does the same as it renders its Python completely 
useless for my work.

Actually, perhaps conda would work for you :-) I'm not clear on what gitHub 
actions allows, but you can certainly use conda on, e.g. TravisCI with OS-X. 
I've only used it to run tests, but I can't see why you couldn't build a app 
that way.

By the way, it's great to "see" all you from back in the day -- this has been a 
very quiet list lately!

-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

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

[Christopher Barker]

On Wed, Mar 11, 2020 at 11:48 PM Just van Rossum 
wrote:

> 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'm pretty sure it can. We've moved to PyInstaller, which does work, and
I'm'pretty sure that py2app can work with conda's non-Framework build.

and it's on conda-forge, so presumably it's worked for at least one person
:-)

https://anaconda.org/conda-forge/py2app

I do recall some issues a while back that have presumably been resolved.


> 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.
>

Actually, perhaps conda would work for you :-) I'm not clear on what gitHub
actions allows, but you can certainly use conda on, e.g. TravisCI with
OS-X. I've only used it to run tests, but I can't see why you couldn't
build a app that way.

By the way, it's great to "see" all you from back in the day -- this has
been a very quiet list lately!

-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

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

[Just van Rossum]

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  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  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 
> 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 

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

[David Brooks]

On 12/03/20 1:11 pm, Christopher Barker wrote:
>> 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 :-(


There is a CMake way to build Python 
, 
used to embed Python into other CMake based applications. The main pain 
in maintaining it is having to work out what has changed in CPython's 
autoconf build when there is a new Python release. Python 3.7 can be 
built (see PRs 257 and 264); Python 3.8 is still WIP; we won't look at 
3.9 until it after it has been released...


What would be really, really nice is for CPython itself to switch to 
CMake -- what is needed to make this happen??




Thanks,

David Brooks
Auckland Bioengineering Institute
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

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

[Christopher Barker]

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  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 
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 

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

[Jack Jansen]

As the person who originally invented (or co-invented? Not quite sure anymore) 
that trick of using a binary inside the App bundle, and the horrible scripts to 
create it: there’s a couple of things worth noting:

- 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.

- I _think_ that the restriction that a GUI program must be in an App bundle no 
longer holds, or at least there are ways around it. 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. 

- 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. 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.

Jack

> On  09-Mar-2020, at 17:53 , Christopher Barker  wrote:
> 
> All,
> 
> (mostly Ned and Ronald...)
> 
> TL:DR:
> 
> Are there any plans to update the build scripts for the python.org python(s)? 
> It would be really nice to get the mac builds more inline with the rest of 
> the Unix world.
> 
> Longer version:
> 
> Over on Conda-forge, we've been struggling with the whole Python.app Bundle 
> thing:
> 
> https://github.com/conda-forge/python.app-feedstock/issues/8
> 
> which resulted in:
> 
> https://github.com/conda-forge/python.app-feedstock/pulls
> 
> Which looks like it's going to solve the "problem at hand".
> 
> (NOTE: what that PR does is put a symlink in the app bundle to the main 
> executable. So pythonw is a bash script that redirects to the symlink in a 
> bundle which is linked to the regular python executable. I'm amazed that it 
> works, but it seems to)
> 
> 
> But really, it seem that it would be better if in the conda world we "did 
> this right", which is to say build a python binary that re-directs to a 
> version inside a bundle to make the OS happy, like is done with the 
> python.org Framework builds.
> 
> There are a number of issues and discussion out there, semi-summaries here:
> 
> https://github.com/conda-forge/python-feedstock/issues/23
> 
> But a summary is:
> 
> The Mac requires that a GUI app executable be "inside" nd application bundle 
> to access the GUI. This means that a regular old python interpreter can not 
> be used to run a GUI app (Tk, wxPython, QT, etc.).
> 
> This was "solved" many years ago in the python.org "Framework" builds of 
> Python, by writing a small wrapper around the pythonexe that re-directs 
> itself to one inside an app bundle. This acts just like a regular command 
> line executalbe, and thus "python" and "pythonw" can be links to the same 
> thing.
> 
> However, when Anaconda (and now conda-forge) started, they did not use a 
> Framework build, preferring to keep python more standardized and *nix-y. So 
> they solved the problem by making a "pythonw" command that is a bash script 
> that re-directs itself to a copy of the python executable inside an 
> application bundle. This is delivered as a "python.app" package via conda.
> 
> However: while this hack works fine from the command line, it does not work 
> with setuptools entry points, and other ways of running the app. This has 
> been a thorn in the side of the (admittedly small) group of folks using both 
> conda and developing OS-X Desktop apps. And the setuptools folks seem to have 
> no interest whatsoever in updating setuptools to accommodate pythonw.
> 
> So what I"d like to see happen is for conda-forge to build its python on OS-X 
> with the little wrapper so that it can be used in place of this whole 
> python.app hack. I think there are not technical reasons that can't be done. 
> But the current configure scripts for python.org don't provide that option, 
> and there has been no one with both an interest in this, the autotools 
> skills, and the time to make it happen.
> 
> I just looked again at the building instructions for the Pyhton.org builds, 
> and they seem to be pretty old. The Mac has moved on and it seems it would b 
> good to updated those build options anyway: Do we need 32 bit anymore? Do we 
> need Universal builds anymore? Should we abandon the Framework build option 
> altogether?
> 
> My proposal: Add a build option that builds Intel, 64bit, fairly recent SDK, 
> and the pythonw hack, into an otherwise "standard" unix-like build. 
> 
> Then that could become the default OS-X build in the 

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

[Ronald Oussoren via Pythonmac-SIG]

> On 9 Mar 2020, at 17:53, Christopher Barker  wrote:
> 
> All,
> 
> (mostly Ned and Ronald...)
> 
> TL:DR:
> 
> Are there any plans to update the build scripts for the python.org 
>  python(s)? It would be really nice to get the mac builds 
> more inline with the rest of the Unix world.

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. The alternative is that users always use py2app/pyinstaller/… to build 
an .app bundle themselves.  

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). 

> 
> Longer version:
> 
> Over on Conda-forge, we've been struggling with the whole Python.app Bundle 
> thing:
> 
> https://github.com/conda-forge/python.app-feedstock/issues/8 
> 
> 
> which resulted in:
> 
> https://github.com/conda-forge/python.app-feedstock/pulls 
> 
> 
> Which looks like it's going to solve the "problem at hand".
> 
> (NOTE: what that PR does is put a symlink in the app bundle to the main 
> executable. So pythonw is a bash script that redirects to the symlink in a 
> bundle which is linked to the regular python executable. I'm amazed that it 
> works, but it seems to)

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 (which is the executable that is 
$prefix/bin/python in unix installs). 
> 
> 
> But really, it seem that it would be better if in the conda world we "did 
> this right", which is to say build a python binary that re-directs to a 
> version inside a bundle to make the OS happy, like is done with the 
> python.org  Framework builds.
> 
> There are a number of issues and discussion out there, semi-summaries here:
> 
> https://github.com/conda-forge/python-feedstock/issues/23 
> 
> 
> But a summary is:
> 
> The Mac requires that a GUI app executable be "inside" nd application bundle 
> to access the GUI. This means that a regular old python interpreter can not 
> be used to run a GUI app (Tk, wxPython, QT, etc.).
> 
> This was "solved" many years ago in the python.org  
> "Framework" builds of Python, by writing a small wrapper around the pythonexe 
> that re-directs itself to one inside an app bundle. This acts just like a 
> regular command line executalbe, and thus "python" and "pythonw" can be links 
> to the same thing.
> 
> However, when Anaconda (and now conda-forge) started, they did not use a 
> Framework build, preferring to keep python more standardized and *nix-y. So 
> they solved the problem by making a "pythonw" command that is a bash script 
> that re-directs itself to a copy of the python executable inside an 
> application bundle. This is delivered as a "python.app" package via conda.
> 
> However: while this hack works fine from the command line, it does not work 
> with setuptools entry points, and other ways of running the app. This has 
> been a thorn in the side of the (admittedly small) group of folks using both 
> conda and developing OS-X Desktop apps. And the setuptools folks seem to have 
> no interest whatsoever in updating setuptools to accommodate pythonw.
> 
> So what I"d like to see happen is for conda-forge to build its python on OS-X 
> with the little wrapper so that it can be used in place of this whole 
> python.app hack. I think there are not technical reasons that can't be done. 
> But the current configure scripts for python.org  don't 
> provide that option, and there has been no one with both an interest in this, 
> the autotools skills, and the time to make it happen.
> 
> I just looked again at the building instructions for the Pyhton.org builds, 
> and they seem to be pretty old. The Mac has moved on and it seems it would b 
> good to updated those build options anyway: Do we need 32 bit anymore? Do we 
> need Universal builds anymore? Should we abandon the Framework build option 
> altogether?
> 
> My proposal: Add a build option that builds Intel, 64bit, fairly recent SDK, 
> and the pythonw hack, into an otherwise "standard" unix-like build. 

What’s wrong with using a framework install? 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).

It should be easy enough to use the pythonw 

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

[Barry Scott]

> On 9 Mar 2020, at 16:53, Christopher Barker  wrote:
> 
> All,
> 
> (mostly Ned and Ronald...)
> 
> TL:DR:
> 
> Are there any plans to update the build scripts for the python.org 
>  python(s)? It would be really nice to get the mac builds 
> more inline with the rest of the Unix world.
> 
> Longer version:
> 
> Over on Conda-forge, we've been struggling with the whole Python.app Bundle 
> thing:

Just curious. I do not seem to have a Python.app on my macOS.
What project makes the python.app? Is it a Conda built .app?

> 
> https://github.com/conda-forge/python.app-feedstock/issues/8 
> 
> 
> which resulted in:
> 
> https://github.com/conda-forge/python.app-feedstock/pulls 
> 
> 
> Which looks like it's going to solve the "problem at hand".
> 
> (NOTE: what that PR does is put a symlink in the app bundle to the main 
> executable. So pythonw is a bash script that redirects to the symlink in a 
> bundle which is linked to the regular python executable. I'm amazed that it 
> works, but it seems to)
> 
> 
> But really, it seem that it would be better if in the conda world we "did 
> this right", which is to say build a python binary that re-directs to a 
> version inside a bundle to make the OS happy, like is done with the 
> python.org  Framework builds.
> 
> There are a number of issues and discussion out there, semi-summaries here:
> 
> https://github.com/conda-forge/python-feedstock/issues/23 
> 
> 
> But a summary is:
> 
> The Mac requires that a GUI app executable be "inside" nd application bundle 
> to access the GUI. This means that a regular old python interpreter can not 
> be used to run a GUI app (Tk, wxPython, QT, etc.).

I can use the /usr/local/bin/python3.7 to run Qt code and the windows appear. I 
do not see any .app running to make this work.
I do this all the time to debug PyQt code so that I can print to stdout.
I do not use the pythonw version and do not recall hitting the problem form the 
command line.

> 
> This was "solved" many years ago in the python.org  
> "Framework" builds of Python, by writing a small wrapper around the pythonexe 
> that re-directs itself to one inside an app bundle. This acts just like a 
> regular command line executalbe, and thus "python" and "pythonw" can be links 
> to the same thing.
> 
> However, when Anaconda (and now conda-forge) started, they did not use a 
> Framework build, preferring to keep python more standardized and *nix-y. So 
> they solved the problem by making a "pythonw" command that is a bash script 
> that re-directs itself to a copy of the python executable inside an 
> application bundle. This is delivered as a "python.app" package via conda.
> 
> However: while this hack works fine from the command line, it does not work 
> with setuptools entry points, and other ways of running the app. This has 
> been a thorn in the side of the (admittedly small) group of folks using both 
> conda and developing OS-X Desktop apps. And the setuptools folks seem to have 
> no interest whatsoever in updating setuptools to accommodate pythonw.
> 
> So what I"d like to see happen is for conda-forge to build its python on OS-X 
> with the little wrapper so that it can be used in place of this whole 
> python.app hack. I think there are not technical reasons that can't be done. 
> But the current configure scripts for python.org  don't 
> provide that option, and there has been no one with both an interest in this, 
> the autotools skills, and the time to make it happen.
> 
> I just looked again at the building instructions for the Pyhton.org builds, 
> and they seem to be pretty old. The Mac has moved on and it seems it would b 
> good to updated those build options anyway: Do we need 32 bit anymore? Do we 
> need Universal builds anymore? Should we abandon the Framework build option 
> altogether?
> 
> My proposal: Add a build option that builds Intel, 64bit, fairly recent SDK, 
> and the pythonw hack, into an otherwise "standard" unix-like build. 
> 
> Then that could become the default OS-X build in the future, exactly when TBD.
> 
> 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 :-)

Barry

> 
> -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: 

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

[Christopher Barker]

All,

(mostly Ned and Ronald...)

TL:DR:

Are there any plans to update the build scripts for the python.org
python(s)? It would be really nice to get the mac builds more inline with
the rest of the Unix world.

Longer version:

Over on Conda-forge, we've been struggling with the whole Python.app Bundle
thing:

https://github.com/conda-forge/python.app-feedstock/issues/8

which resulted in:

https://github.com/conda-forge/python.app-feedstock/pulls

Which looks like it's going to solve the "problem at hand".

(NOTE: what that PR does is put a symlink in the app bundle to the main
executable. So pythonw is a bash script that redirects to the symlink in a
bundle which is linked to the regular python executable. I'm amazed that it
works, but it seems to)


But really, it seem that it would be better if in the conda world we "did
this right", which is to say build a python binary that re-directs to a
version inside a bundle to make the OS happy, like is done with the
python.org Framework builds.

There are a number of issues and discussion out there, semi-summaries here:

https://github.com/conda-forge/python-feedstock/issues/23

But a summary is:

The Mac requires that a GUI app executable be "inside" nd application
bundle to access the GUI. This means that a regular old python interpreter
can not be used to run a GUI app (Tk, wxPython, QT, etc.).

This was "solved" many years ago in the python.org "Framework" builds of
Python, by writing a small wrapper around the pythonexe that re-directs
itself to one inside an app bundle. This acts just like a regular command
line executalbe, and thus "python" and "pythonw" can be links to the same
thing.

However, when Anaconda (and now conda-forge) started, they did not use a
Framework build, preferring to keep python more standardized and *nix-y. So
they solved the problem by making a "pythonw" command that is a bash script
that re-directs itself to a copy of the python executable inside an
application bundle. This is delivered as a "python.app" package via conda.

However: while this hack works fine from the command line, it does not work
with setuptools entry points, and other ways of running the app. This has
been a thorn in the side of the (admittedly small) group of folks using
both conda and developing OS-X Desktop apps. And the setuptools folks seem
to have no interest whatsoever in updating setuptools to accommodate
pythonw.

So what I"d like to see happen is for conda-forge to build its python on
OS-X with the little wrapper so that it can be used in place of this whole
python.app hack. I think there are not technical reasons that can't be
done. But the current configure scripts for python.org don't provide that
option, and there has been no one with both an interest in this, the
autotools skills, and the time to make it happen.

I just looked again at the building instructions for the Pyhton.org builds,
and they seem to be pretty old. The Mac has moved on and it seems it would
b good to updated those build options anyway: Do we need 32 bit anymore? Do
we need Universal builds anymore? Should we abandon the Framework build
option altogether?

My proposal: Add a build option that builds Intel, 64bit, fairly recent
SDK, and the pythonw hack, into an otherwise "standard" unix-like build.

Then that could become the default OS-X build in the future, exactly when
TBD.

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 :-)

-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