Re: [Pythonmac-SIG] "pythonw" in a Unix build

[Christopher Barker]

On Mon, Jan 18, 2021 at 4:33 PM Jack Jansen  wrote:

> it still isn't clear to me _why_ you wouldn’t want to use a framework
> build…
>

on a personal level, it's because the conda folks really want to use a
plain vanilla unix build -- and I want things to work with conda.

As to why conda wants to do that, my thoughts:

conda manages not just Python, but also a full set of other libraries, and
even other languages (R, Julia, Java).

In that way, it's a bit like homebrew or macports.

However, It also tries to be as platform-neutral as possible, so anything
that works one way on conda works that same way on all platforms.

And in practice, it solves a LOT of problems, problems that were a pain in
the neck for years on the Mac.

Also in practice, treating OS-X as "just another unix" works quite well in
almost all ways -- there are a few addicted here than there, though those
are mostly about clang than OS-X per se. But most things "just work".


> The whole exercise feels a bit like discussions from 15 years ago, with
> Unix wizards who wanted MacOS to behave as if it was plain vanilla Unix
> without all the things Apple changed. And that is much less true today than
> it was then…
>

Another practical consideration is that the vast majority of Python
developers that use Macs use them like a Unix system: data analysis, web
development, etc, etc. It's only desktop GUI software that poses any
issues, and this is the only issue (that I know of) for that.

There was an experiment with using a Framework build in conda a while back
-- it immediately ran into the issue that it would be incompatible with all
existing conda-python packages, so that's not good. It could be that that
could be addressed with appropriate symlinks, but not one did a thorough
testing.

Another issue is that conda now supports platform-independent Python
packages -- and that would get a lot harder with a Framework build. (though
again, maybe a full set of links could solve that)

It's also the case that using a Framework build inside conda buys us
absolutely nothing -- it just makes things gratuitously different from the
other *nix systems for no gain. I appreciate the idea of frameworks, but a)
I don't think Frameworks were really designed for things like python
anyway, and b) conda is solving all the problems that Frameworks solve but
-- in a different, and platform independent way.

In short: building python as a framework in conda would create an
incompatibility with no gain. The only reason to do it would be to get the
"pythonw" executable, and that doesn't actually require a Framework --
"just" some new build scripts.

Anyway, if the folks that want this do the work, it looks like it can
happen, and if not, then I guess we won't get it.

Fair enough.

-Chris


On  18-Jan-2021, at 18:38 , Christopher Barker  wrote:
>
> On Mon, Jan 18, 2021 at 1:34 AM Ronald Oussoren 
> wrote:
>
>> As mentioned on python-dev adding the “pythonw” functionality to the unix
>> build is not very hard. I expect that integrating with the build system
>> (Makefile/configure script) will be the hardest part due to introducing
>> different behaviour for the macOS platform.
>>
>
> Thanks Ronald, that confirms my suspicions that this is really an autoconf
> issue. Which makes it an utter mystery to me :-(
>
>> And we already have a work around in the core python code, it's just that
>> the build system needs to be set up to build it outside of a Framework.
>>
>> The framework build does not have a workaround for these problems, it has
>> a proper solution ;-).
>>
>
> Glad to hear that -- in earlier conversations, I got the impression that
> you thought the executable wrapper was kind of a hack :-).
>
> Anyway -- if any of you have autoconf expertise and the inclination, I'd
> love to see this get done, and would be glad to help as best I can.
>
> -CHB
>
> --
> Christopher Barker, PhD (Chris)
>
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython
>
>
> --
>
> Jack Jansen, , 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 (Chris)

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] "pythonw" in a Unix build

[Jack Jansen]

Christopher,
it still isn't clear to me _why_ you wouldn’t want to use a framework build…

The whole exercise feels a bit like discussions from 15 years ago, with Unix 
wizards who wanted MacOS to behave as if it was plain vanilla Unix without all 
the things Apple changed. And that is much less true today than it was then… 

Jack

> On  18-Jan-2021, at 18:38 , Christopher Barker  wrote:
> 
> On Mon, Jan 18, 2021 at 1:34 AM Ronald Oussoren  > wrote:
> As mentioned on python-dev adding the “pythonw” functionality to the unix 
> build is not very hard. I expect that integrating with the build system 
> (Makefile/configure script) will be the hardest part due to introducing 
> different behaviour for the macOS platform. 
> 
> Thanks Ronald, that confirms my suspicions that this is really an autoconf 
> issue. Which makes it an utter mystery to me :-(
>> And we already have a work around in the core python code, it's just that 
>> the build system needs to be set up to build it outside of a Framework.
> The framework build does not have a workaround for these problems, it has a 
> proper solution ;-). 
> 
> Glad to hear that -- in earlier conversations, I got the impression that you 
> thought the executable wrapper was kind of a hack :-).
> 
> Anyway -- if any of you have autoconf expertise and the inclination, I'd love 
> to see this get done, and would be glad to help as best I can.
> 
> -CHB
>  
> -- 
> Christopher Barker, PhD (Chris)
> 
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython

--
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] "pythonw" in a Unix build

[Christopher Barker]

On Mon, Jan 18, 2021 at 1:34 AM Ronald Oussoren 
wrote:

> As mentioned on python-dev adding the “pythonw” functionality to the unix
> build is not very hard. I expect that integrating with the build system
> (Makefile/configure script) will be the hardest part due to introducing
> different behaviour for the macOS platform.
>

Thanks Ronald, that confirms my suspicions that this is really an autoconf
issue. Which makes it an utter mystery to me :-(

> And we already have a work around in the core python code, it's just that
> the build system needs to be set up to build it outside of a Framework.
>
> The framework build does not have a workaround for these problems, it has
> a proper solution ;-).
>

Glad to hear that -- in earlier conversations, I got the impression that
you thought the executable wrapper was kind of a hack :-).

Anyway -- if any of you have autoconf expertise and the inclination, I'd
love to see this get done, and would be glad to help as best I can.

-CHB

-- 
Christopher Barker, PhD (Chris)

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] "pythonw" in a Unix build

[Ronald Oussoren via Pythonmac-SIG]

> On 15 Jan 2021, at 06:24, Christopher Barker  wrote:
> 
> On Thu, Jan 14, 2021 at 3:14 PM Jack Jansen  > wrote:
> For example, the brew Python is installed into a framework tucked away deep 
> in /usr/local/Cellar but you don’t notice this at all: you can just use 
> “python foo.py” and the moment the script does GUI calls it’ll get an icon in 
> the doc and all that.
> 
> What problem are you trying to solve?
> 
> It's interesting that brew python has decided to use a Framework build 
> 
> But the problem at hand is conda python which used a plain unix build.

Maybe they should switch to a framework build instead :-)

> 
> They have provided a shell script "pythonw" that re-directs to a python 
> inside an app bundle, and that works OK on the command line, but it does not 
> work with, e.g. setuptools entry points.
> 
> I could dig up the threads, but this has been discussed on this list, and few 
> gitHub issues. 

As mentioned on python-dev adding the “pythonw” functionality to the unix build 
is not very hard. I expect that integrating with the build system 
(Makefile/configure script) will be the hardest part due to introducing 
different behaviour for the macOS platform. 

> 
> In short, there are a few ways to work around these issues, but no one (the 
> conda people, the setuptools devs) wants to put the kludgy work around in 
> their code.
> 
> And we already have a work around in the core python code, it's just that the 
> build system needs to be set up to build it outside of a Framework.

The framework build does not have a workaround for these problems, it has a 
proper solution ;-). 

Ronald

> 
> -CHB
> 
> 
>  
> Jack
> 
>> On  14-Jan-2021, at 23:07 , Chris Barker via Pythonmac-SIG 
>> mailto:pythonmac-sig@python.org>> wrote:
>> 
>> Ned suggested I bring this conversation over here from python-dev, so here 
>> it is.
>> 
>> What I'd like to see done is have the "pythonw" wrapper buildable in an 
>> otherwise non-framework build.
>> 
>> I *think* there are no real technical show stoppers, but it would take some 
>> auto-conf magic, which I am fully unqualified to take on.
>> 
>> Anyone interested in helping make this happen ?
>> 
>> -CHB
>> 
>> 
>> -- 
>> 
>> Christopher Barker, Ph.D.
>> Oceanographer
>> 
>> Emergency Response Division
>> NOAA/NOS/OR(206) 526-6959   voice
>> 7600 Sand Point Way NE   (206) 526-6329   fax
>> Seattle, WA  98115   (206) 526-6317   main reception
>> 
>> chris.bar...@noaa.gov 
>> ___
>> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org 
>> 
>> https://mail.python.org/mailman/listinfo/pythonmac-sig 
>> 
>> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG 
>> 
> 
> --
> 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 
> 
> 
> 
> -- 
> Christopher Barker, PhD (Chris)
> 
> 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 
> 
—

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