[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 <jack.jansen at cwi.nl> 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 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.
>

That's exactly what Anaconda (the distribution) does now. It tries to be as
consistent across platforms as it can. But that doesn't mean it doesn need
MAc features at all -- it provides a number GUI programs (including it's
own application manager) I think these are mostly written using QT, so are
not terribly MAc-native, but they need to run.

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
>

See above -- no none would install Anaconda (or conda) via brew. conda is
pretty much a replacement for brew.


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

This is pretty much what Anaconda is now, but without the Framework-specifc
stuff -- and it does work.

And I don't think there would ever be two "Anacondas"

In theory, you could have two different Python packages for conda: python_u
and pyrthon_f. But I think that would create a nightmare for all the
dependent packages -- anything that required, say, python3.8 may have to be
built differently depending on which python build you had. It's possible
that that could be worked around with a lot of symlinks, so that they would
appear to tbe the same. But if that can work, then why not simply have one
build anyway.

Which reminds me of a reason not to use a Framework build for conda: You
can now have "noarch" packages -- if the contents of the code is the same
for all platforms (like a typical pure python package) then you can have a
single package that can be used on all platforms. Which means that the
directory layout  has to be the same everywhere. Which maybe could be
accomplished with symlnks, but it would be a bit of a mess.

Anyway, I think that the conda use case defined above would be well
suppoted by essentially a standard *nix build, but with the executable
redirecting to inside an app bundle trick.

That would also work fine for the "Unix folks" -- for brew and the like.

The only question I'm not sure on is if it would work for the
point-and-click-install on the MAc use-case -- that use case may best be
served by the Framework build and installer that we already have.

- Chris


-- 
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/20200314/35081a18/attachment.html>