<div dir="ltr"><div dir="ltr"><div>Thanks Jack.</div><div><br></div><div>But I'm still confused about a technical question:</div><div><br></div><div>Does having python itself in a Framework enable anything that having it outside a Framework won't let you do?</div><div><br></div><div>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 <a href="http://python.org">python.org</a> build scripts, but a Framework in the general sense.<br></div><div><br></div><div>Second: the whole intertwining of conda, Anaconda, brew, etc, is very confusing, so I'll try to provide a bit of clarity here:</div><div><br></div><div>I think we all know what brew (and macports, if anything is still using that) is.</div><div><br></div><div>but "conda" is a package management tool, a bit like yum or apt in the Linux world, or Brew, for that matter. except that:</div><div><br></div><div>* It is platform independent -- it attempts to work the same way on all all platforms to the degree possible.</div><div>* 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.</div><div><br></div><div>* critically, it can manage, in theory, ANY software or library -- including Python, of course.<br></div><div>* conda is written in Python, but otherwise but is not specifically about Python.</div><div>*  In practice, it is currently used mostly for Python and associated libraries, but also R, node.js, geospatial libraries and tools, etc.</div><div><br></div><div>"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.</div><div><br></div><div>Importantly, conda the package manager, can be, and is, used to manage collections of software without Anaconda (see "miniconda) </div><div><br></div><div>In theory, anyone could build and distribute conda packages in any way (or build then themselves and entirely self manage them). In practice, THe <a href="http://anaconda.org">anaconda.org</a> site is used as a repository of packages. Anyone can set up their own "channel" and distribute whatever they want.</div><div><br></div><div>In addition to the packages being distributed by the Anaconda company, and a whole variety of private channels on <a href="http://anaconda.org">anaconda.org</a>, there is the "conda-forge" project, which is a community-driven curated collection of a packages available on <a href="http://anaconda.org">anaconda.org</a>, and managed by a big ol' gitHub org.</div><div><br></div><div>Now that that's done:<br></div><br></div>On Sat, Mar 14, 2020 at 4:41 PM Jack Jansen <<a href="mailto:jack.jansen@cwi.nl">jack.jansen@cwi.nl</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">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.</div></blockquote><div><br></div><div>I agree -- there are different needs for different audiences, and there may not be one single way to build Python that meats all needs.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div>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).</div></div></blockquote><div><br></div><div>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.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div>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.</div></div></blockquote><div><br></div><div>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.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div>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.</div></div></blockquote><div><br></div><div>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 )<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div> 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.</div></div></blockquote><div><br></div><div>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.<br></div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div>And if you can’t decide: how much work would it be to have two Anaconda distributions for the Mac: </div><div>- one that is primarily Unix-y, installed through brew, intended to be used from the command line, and with the MagicMacPythonWrapper</div></div></blockquote><div><br></div><div>See above -- no none would install Anaconda (or conda) via brew. conda is pretty much a replacement for brew.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div>- 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.</div></div></blockquote><div><br></div><div>This is pretty much what Anaconda is now, but without the Framework-specifc stuff -- and it does work.<br></div><div><br></div><div>And I don't think there would ever be two "Anacondas"</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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. <br></div><div><br></div><div>That would also work fine for the "Unix folks" -- for brew and the like.</div><div><br></div>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.<br><div><br></div><div>- Chris<br></div><div><br></div></div><br>-- <br><div dir="ltr" class="gmail_signature">Christopher Barker, PhD<br><br> Python Language Consulting<br>  - Teaching<br>  - Scientific Software Development<br>  - Desktop GUI and Web Development<br>  - wxPython, numpy, scipy, Cython<br></div></div>