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

Wed Mar 11 20:11:10 EDT 2020

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 <jack.jansen at cwi.nl> 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 <ronaldoussoren at mac.com>
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 of
a concern from Conda because the tool manages installation and
deinstallation for the user).

Exactly, the entire point of conda is to manage all that for you. And it
manages the entire environment, Python, other libs, even R and Noide if you
want. I used to use the Python Framework, and the OSGEO Frameworks that
Kyng Chaos put together (https://www.kyngchaos.com/software/frameworks/),
and assorted stuff from macport, then brew .... Trust me, conda makes this
MUCH easier. And particulary easier to have multipel versions of things
installed.

> It should be easy enough to use the pythonw “hack” from the
Python.framework with a Unix install, the hard part is tweaking the build
process (in particular the Makefile).

Good to know, that's what I suspected. That still seems like the way to go,
unless we can get the GUI toolkits to not require this anymore ...

> BTW. I’d prefer to not add yet another build configuration on macOS,
having both Unix and Framework installs is confusing enough.

well, ideally, maybe we could jetison a few of the older options!

> If the pythonw “hack” is considered useful for Unix installs it should be
enabled unconditionally in 3.9.

I agree. That's kinda the point.

> BTW. Looking further toward the future I’d love to spent time on creating
a “Python.app” that replaces the current framework installers, with some
effort that could remove the need to run installers at all and might even
make it possible to distribute Python through the macOS App Store.

That might be nice -- I htink you have two user groups:
1) Folks that need a quick, easy way to install Python to run with an IDE,
or ...
2) Folks that want to build themselves (or really, to build as part of
another distrobution system: conda, macports, brew, what have you

But what would a Python.App actually be? The fact is that Python is not an
application in the usual sense. It really is a command line system tool and
libraries, and ... It should be installed that way. If that can be done by
the app store, great.

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

Thanks,

-CHB

-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20200311/983b54d6/attachment-0001.html>