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

Thu Mar 12 02:48:44 EDT 2020

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 <pythonchb at gmail.com> 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 <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
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20200312/f39a6f02/attachment-0001.html>