Thanks Ronald,

This  is really helpful.

-CHB

On Fri, Jan 15, 2021 at 5:43 AM Ronald Oussoren <ronaldousso...@mac.com>
wrote:

>
>
> On 14 Jan 2021, at 23:03, Chris Barker via Python-Dev <
> python-dev@python.org> wrote:
>
> Ned,
>
> Thanks -- I'll take further discussion to the python-mac list.
>
> Ronald:
>
> That’s a feature of the framework build. The unix build is exactly the
>> same as a unix build on other platform.  Adding the same feature to the
>> unix build should be possible, but would complicate the build.  I have no
>> interest to work on this, but would be willing to review PRs,
>>
>
> fair enough.
>
>
>> as long as those aim for feature parity with the framework build. That
>> is, both pythonw(1) and python(1) should redirect through an embedded app
>> bundle.
>>
>
> yes, that's what I'm thinking.
>
> Done, just configure “—enable-universalsdk
>> —with-universal-archs=universal2” without specifying a framework build.
>>
>
> Excellent, thanks!
>
> Something I would like to work on, but don’t have enough free time for, is
>> an alternative installation with an application bundle on the top level
>> instead of a framework.  Installation would then entail dropping “Python
>> X.Y.app” into your application folder, and uninstallation would be to drop
>> the same bundle into the bin.
>>
>
> That would be nice -- and would, I think, actually buy us something useful
> from this bundling :-)
>
>
> To be honest I’d expect that this will also lead to complaining about how
> this build is not a unix build ;-)
>
>
> Just don’t use conda ;-).  To be blunt, doing this properly is trivial.
>>
>
> which "this" are you referring to -- and if it's trivial, then why hasn't
> anyone figured out how in multiple conversations over years?
>
> “This” is having a pythonw that’s the same as in framework builds.
>
> I don’t know. I do know that nobody asked questions about this before.
>
>
> But if it is -- tell us how and maybe we will do it (if it's really
> trivial, maybe even I, with my limited build skills could do it)
>
>
>
> For anyone reading along that isn’t familiar with macOS: On macOS a number
> of system libraries, and in particular GUI libraries, require that they are
> used from an application bundle (‘.app”).   For Python we want to be able
> to just use the command-line for simple scripts (and testing of more
> complicated applications), instead having to build an app bundle every time.
>
> In framework builds this is solved by two changes relative to a unix build:
> 1. The regular python binary is in
> “{sys.prefix}/Resources/Python.app/Contents/MacOS/Python”
> 2. “{sys.executable}” (or “{sys.prefix}/bin/python3”) is a stub executable
> that does nothing but execv[1] the regular python binary. The source of
> this binary is in Mac/Tools/pythonw.c
>
>
> Note: All of this requires using a shared library build (—enable-shared)
> because of the way the stub finds sys.prefix.
>
> To add this to the unix build as well requires:
> 1. Make up a location for the Python.app
> 2. Change the Makefile(.pre.in) to build the stub executable install
> files in their new location, but only when installing on macOS with an
> —enable-shared build
> 3. Tweak the code in pythonw.c to calculate the correct path to Python.app
> 4. Possibly tweak the calculation of sys.prefix for unix builds, IIRC the
> special macOS sauce is enabled for framework builds only
> 5. Do some debugging because this list is likely incomplete, I typed it
> from memory
>
>
> Ronald
>
> [1] for the pedantically correct: it actually uses posix_spawn in exec
> mode to ensure that the correct CPU architecture is used. That’s why “arch
> -x86_64 python3.9” works when you use the universal2 installer for python
> 3.9, if we’d use execv the stub would launch the actual interpreter in
> native mode.
>
> Ronald
>
>
> Thanks,
>
> -CHB
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R            (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
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/7YZ4JB5PTL2LKGRCNZF7X4TP7ZYTBW3H/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
> —
>
> Twitter / micro.blog: @ronaldoussoren
> Blog: https://blog.ronaldoussoren.net/
>
>

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (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
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/GTEJODZQTCIL3OTEJ2MMY52ERMJJGNYJ/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to