From ronaldoussoren at mac.com Sun Mar 1 16:36:07 2020 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sun, 1 Mar 2020 22:36:07 +0100 Subject: [Pythonmac-SIG] ANN: PyObjC moved to GitHub Message-ID: Hi, I?ve moved the PyObjC repository from BitBucket to GitHub. The new home is: https://github.com/ronaldoussoren/pyobjc/ I expect to release a new version of PyObjC soon after the release of macOS 10.15.4. Ronald ? Twitter: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pythonchb at gmail.com Mon Mar 9 12:53:07 2020 From: pythonchb at gmail.com (Christopher Barker) Date: Mon, 9 Mar 2020 09:53:07 -0700 Subject: [Pythonmac-SIG] Building plans ..... Message-ID: All, (mostly Ned and Ronald...) TL:DR: Are there any plans to update the build scripts for the python.org python(s)? It would be really nice to get the mac builds more inline with the rest of the Unix world. Longer version: Over on Conda-forge, we've been struggling with the whole Python.app Bundle thing: https://github.com/conda-forge/python.app-feedstock/issues/8 which resulted in: https://github.com/conda-forge/python.app-feedstock/pulls Which looks like it's going to solve the "problem at hand". (NOTE: what that PR does is put a symlink in the app bundle to the main executable. So pythonw is a bash script that redirects to the symlink in a bundle which is linked to the regular python executable. I'm amazed that it works, but it seems to) But really, it seem that it would be better if in the conda world we "did this right", which is to say build a python binary that re-directs to a version inside a bundle to make the OS happy, like is done with the python.org Framework builds. There are a number of issues and discussion out there, semi-summaries here: https://github.com/conda-forge/python-feedstock/issues/23 But a summary is: The Mac requires that a GUI app executable be "inside" nd application bundle to access the GUI. This means that a regular old python interpreter can not be used to run a GUI app (Tk, wxPython, QT, etc.). This was "solved" many years ago in the python.org "Framework" builds of Python, by writing a small wrapper around the pythonexe that re-directs itself to one inside an app bundle. This acts just like a regular command line executalbe, and thus "python" and "pythonw" can be links to the same thing. However, when Anaconda (and now conda-forge) started, they did not use a Framework build, preferring to keep python more standardized and *nix-y. So they solved the problem by making a "pythonw" command that is a bash script that re-directs itself to a copy of the python executable inside an application bundle. This is delivered as a "python.app" package via conda. However: while this hack works fine from the command line, it does not work with setuptools entry points, and other ways of running the app. This has been a thorn in the side of the (admittedly small) group of folks using both conda and developing OS-X Desktop apps. And the setuptools folks seem to have no interest whatsoever in updating setuptools to accommodate pythonw. So what I"d like to see happen is for conda-forge to build its python on OS-X with the little wrapper so that it can be used in place of this whole python.app hack. I think there are not technical reasons that can't be done. But the current configure scripts for python.org don't provide that option, and there has been no one with both an interest in this, the autotools skills, and the time to make it happen. I just looked again at the building instructions for the Pyhton.org builds, and they seem to be pretty old. The Mac has moved on and it seems it would b good to updated those build options anyway: Do we need 32 bit anymore? Do we need Universal builds anymore? Should we abandon the Framework build option altogether? My proposal: Add a build option that builds Intel, 64bit, fairly recent SDK, and the pythonw hack, into an otherwise "standard" unix-like build. Then that could become the default OS-X build in the future, exactly when TBD. 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 :-) -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: From barry at barrys-emacs.org Mon Mar 9 13:10:07 2020 From: barry at barrys-emacs.org (Barry Scott) Date: Mon, 9 Mar 2020 17:10:07 +0000 Subject: [Pythonmac-SIG] Building plans ..... In-Reply-To: References: Message-ID: > On 9 Mar 2020, at 16:53, Christopher Barker wrote: > > All, > > (mostly Ned and Ronald...) > > TL:DR: > > Are there any plans to update the build scripts for the python.org python(s)? It would be really nice to get the mac builds more inline with the rest of the Unix world. > > Longer version: > > Over on Conda-forge, we've been struggling with the whole Python.app Bundle thing: Just curious. I do not seem to have a Python.app on my macOS. What project makes the python.app? Is it a Conda built .app? > > https://github.com/conda-forge/python.app-feedstock/issues/8 > > which resulted in: > > https://github.com/conda-forge/python.app-feedstock/pulls > > Which looks like it's going to solve the "problem at hand". > > (NOTE: what that PR does is put a symlink in the app bundle to the main executable. So pythonw is a bash script that redirects to the symlink in a bundle which is linked to the regular python executable. I'm amazed that it works, but it seems to) > > > But really, it seem that it would be better if in the conda world we "did this right", which is to say build a python binary that re-directs to a version inside a bundle to make the OS happy, like is done with the python.org Framework builds. > > There are a number of issues and discussion out there, semi-summaries here: > > https://github.com/conda-forge/python-feedstock/issues/23 > > But a summary is: > > The Mac requires that a GUI app executable be "inside" nd application bundle to access the GUI. This means that a regular old python interpreter can not be used to run a GUI app (Tk, wxPython, QT, etc.). I can use the /usr/local/bin/python3.7 to run Qt code and the windows appear. I do not see any .app running to make this work. I do this all the time to debug PyQt code so that I can print to stdout. I do not use the pythonw version and do not recall hitting the problem form the command line. > > This was "solved" many years ago in the python.org "Framework" builds of Python, by writing a small wrapper around the pythonexe that re-directs itself to one inside an app bundle. This acts just like a regular command line executalbe, and thus "python" and "pythonw" can be links to the same thing. > > However, when Anaconda (and now conda-forge) started, they did not use a Framework build, preferring to keep python more standardized and *nix-y. So they solved the problem by making a "pythonw" command that is a bash script that re-directs itself to a copy of the python executable inside an application bundle. This is delivered as a "python.app" package via conda. > > However: while this hack works fine from the command line, it does not work with setuptools entry points, and other ways of running the app. This has been a thorn in the side of the (admittedly small) group of folks using both conda and developing OS-X Desktop apps. And the setuptools folks seem to have no interest whatsoever in updating setuptools to accommodate pythonw. > > So what I"d like to see happen is for conda-forge to build its python on OS-X with the little wrapper so that it can be used in place of this whole python.app hack. I think there are not technical reasons that can't be done. But the current configure scripts for python.org don't provide that option, and there has been no one with both an interest in this, the autotools skills, and the time to make it happen. > > I just looked again at the building instructions for the Pyhton.org builds, and they seem to be pretty old. The Mac has moved on and it seems it would b good to updated those build options anyway: Do we need 32 bit anymore? Do we need Universal builds anymore? Should we abandon the Framework build option altogether? > > My proposal: Add a build option that builds Intel, 64bit, fairly recent SDK, and the pythonw hack, into an otherwise "standard" unix-like build. > > Then that could become the default OS-X build in the future, exactly when TBD. > > 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 :-) Barry > > -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: From ronaldoussoren at mac.com Wed Mar 11 10:58:31 2020 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 11 Mar 2020 15:58:31 +0100 Subject: [Pythonmac-SIG] Building plans ..... In-Reply-To: References: Message-ID: <8783FD09-E376-4C2D-8394-0DA5367FAE57@mac.com> > On 9 Mar 2020, at 17:53, Christopher Barker wrote: > > All, > > (mostly Ned and Ronald...) > > TL:DR: > > Are there any plans to update the build scripts for the python.org python(s)? It would be really nice to get the mac builds more inline with the rest of the Unix world. 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. The alternative is that users always use py2app/pyinstaller/? to build an .app bundle themselves. 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). > > Longer version: > > Over on Conda-forge, we've been struggling with the whole Python.app Bundle thing: > > https://github.com/conda-forge/python.app-feedstock/issues/8 > > which resulted in: > > https://github.com/conda-forge/python.app-feedstock/pulls > > Which looks like it's going to solve the "problem at hand". > > (NOTE: what that PR does is put a symlink in the app bundle to the main executable. So pythonw is a bash script that redirects to the symlink in a bundle which is linked to the regular python executable. I'm amazed that it works, but it seems to) 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 (which is the executable that is $prefix/bin/python in unix installs). > > > But really, it seem that it would be better if in the conda world we "did this right", which is to say build a python binary that re-directs to a version inside a bundle to make the OS happy, like is done with the python.org Framework builds. > > There are a number of issues and discussion out there, semi-summaries here: > > https://github.com/conda-forge/python-feedstock/issues/23 > > But a summary is: > > The Mac requires that a GUI app executable be "inside" nd application bundle to access the GUI. This means that a regular old python interpreter can not be used to run a GUI app (Tk, wxPython, QT, etc.). > > This was "solved" many years ago in the python.org "Framework" builds of Python, by writing a small wrapper around the pythonexe that re-directs itself to one inside an app bundle. This acts just like a regular command line executalbe, and thus "python" and "pythonw" can be links to the same thing. > > However, when Anaconda (and now conda-forge) started, they did not use a Framework build, preferring to keep python more standardized and *nix-y. So they solved the problem by making a "pythonw" command that is a bash script that re-directs itself to a copy of the python executable inside an application bundle. This is delivered as a "python.app" package via conda. > > However: while this hack works fine from the command line, it does not work with setuptools entry points, and other ways of running the app. This has been a thorn in the side of the (admittedly small) group of folks using both conda and developing OS-X Desktop apps. And the setuptools folks seem to have no interest whatsoever in updating setuptools to accommodate pythonw. > > So what I"d like to see happen is for conda-forge to build its python on OS-X with the little wrapper so that it can be used in place of this whole python.app hack. I think there are not technical reasons that can't be done. But the current configure scripts for python.org don't provide that option, and there has been no one with both an interest in this, the autotools skills, and the time to make it happen. > > I just looked again at the building instructions for the Pyhton.org builds, and they seem to be pretty old. The Mac has moved on and it seems it would b good to updated those build options anyway: Do we need 32 bit anymore? Do we need Universal builds anymore? Should we abandon the Framework build option altogether? > > My proposal: Add a build option that builds Intel, 64bit, fairly recent SDK, and the pythonw hack, into an otherwise "standard" unix-like build. What?s wrong with using a framework install? 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). 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). BTW. I?d prefer to not add yet another build configuration on macOS, having both Unix and Framework installs is confusing enough. If the pythonw ?hack? is considered useful for Unix installs it should be enabled unconditionally in 3.9. > > Then that could become the default OS-X build in the future, exactly when TBD. 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. > > 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 ;-). Ronald > > -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: From jack.jansen at cwi.nl Wed Mar 11 17:34:13 2020 From: jack.jansen at cwi.nl (Jack Jansen) Date: Wed, 11 Mar 2020 22:34:13 +0100 Subject: [Pythonmac-SIG] Building plans ..... In-Reply-To: References: Message-ID: As the person who originally invented (or co-invented? Not quite sure anymore) that trick of using a binary inside the App bundle, and the horrible scripts to create it: there?s a couple of things worth noting: - 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. - I _think_ that the restriction that a GUI program must be in an App bundle no longer holds, or at least there are ways around it. 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. - 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. 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. Jack > On 09-Mar-2020, at 17:53 , Christopher Barker wrote: > > All, > > (mostly Ned and Ronald...) > > TL:DR: > > Are there any plans to update the build scripts for the python.org python(s)? It would be really nice to get the mac builds more inline with the rest of the Unix world. > > Longer version: > > Over on Conda-forge, we've been struggling with the whole Python.app Bundle thing: > > https://github.com/conda-forge/python.app-feedstock/issues/8 > > which resulted in: > > https://github.com/conda-forge/python.app-feedstock/pulls > > Which looks like it's going to solve the "problem at hand". > > (NOTE: what that PR does is put a symlink in the app bundle to the main executable. So pythonw is a bash script that redirects to the symlink in a bundle which is linked to the regular python executable. I'm amazed that it works, but it seems to) > > > But really, it seem that it would be better if in the conda world we "did this right", which is to say build a python binary that re-directs to a version inside a bundle to make the OS happy, like is done with the python.org Framework builds. > > There are a number of issues and discussion out there, semi-summaries here: > > https://github.com/conda-forge/python-feedstock/issues/23 > > But a summary is: > > The Mac requires that a GUI app executable be "inside" nd application bundle to access the GUI. This means that a regular old python interpreter can not be used to run a GUI app (Tk, wxPython, QT, etc.). > > This was "solved" many years ago in the python.org "Framework" builds of Python, by writing a small wrapper around the pythonexe that re-directs itself to one inside an app bundle. This acts just like a regular command line executalbe, and thus "python" and "pythonw" can be links to the same thing. > > However, when Anaconda (and now conda-forge) started, they did not use a Framework build, preferring to keep python more standardized and *nix-y. So they solved the problem by making a "pythonw" command that is a bash script that re-directs itself to a copy of the python executable inside an application bundle. This is delivered as a "python.app" package via conda. > > However: while this hack works fine from the command line, it does not work with setuptools entry points, and other ways of running the app. This has been a thorn in the side of the (admittedly small) group of folks using both conda and developing OS-X Desktop apps. And the setuptools folks seem to have no interest whatsoever in updating setuptools to accommodate pythonw. > > So what I"d like to see happen is for conda-forge to build its python on OS-X with the little wrapper so that it can be used in place of this whole python.app hack. I think there are not technical reasons that can't be done. But the current configure scripts for python.org don't provide that option, and there has been no one with both an interest in this, the autotools skills, and the time to make it happen. > > I just looked again at the building instructions for the Pyhton.org builds, and they seem to be pretty old. The Mac has moved on and it seems it would b good to updated those build options anyway: Do we need 32 bit anymore? Do we need Universal builds anymore? Should we abandon the Framework build option altogether? > > My proposal: Add a build option that builds Intel, 64bit, fairly recent SDK, and the pythonw hack, into an otherwise "standard" unix-like build. > > Then that could become the default OS-X build in the future, exactly when TBD. > > 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 :-) > > -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 -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From pythonchb at gmail.com Wed Mar 11 20:11:10 2020 From: pythonchb at gmail.com (Christopher Barker) Date: Wed, 11 Mar 2020 17:11:10 -0700 Subject: [Pythonmac-SIG] Building plans ..... In-Reply-To: References: Message-ID: 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 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 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: From dave at bcs.co.nz Wed Mar 11 20:58:06 2020 From: dave at bcs.co.nz (David Brooks) Date: Thu, 12 Mar 2020 13:58:06 +1300 Subject: [Pythonmac-SIG] Building plans ..... In-Reply-To: References: Message-ID: <6f861db5-8509-0058-efb1-0db2c39217df@bcs.co.nz> On 12/03/20 1:11 pm, Christopher Barker wrote: > >> 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 :-( > > There is a CMake way to build Python , used to embed Python into other CMake based applications. The main pain in maintaining it is having to work out what has changed in CPython's autoconf build when there is a new Python release. Python 3.7 can be built (see PRs 257 and 264); Python 3.8 is still WIP; we won't look at 3.9 until it after it has been released... What would be really, really nice is for CPython itself to switch to CMake -- what is needed to make this happen?? Thanks, David Brooks Auckland Bioengineering Institute -------------- next part -------------- An HTML attachment was scrubbed... URL: From justvanrossum at gmail.com Thu Mar 12 02:48:44 2020 From: justvanrossum at gmail.com (Just van Rossum) Date: Thu, 12 Mar 2020 07:48:44 +0100 Subject: [Pythonmac-SIG] Building plans ..... In-Reply-To: References: Message-ID: 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 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 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 > 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: From pythonchb at gmail.com Thu Mar 12 12:26:22 2020 From: pythonchb at gmail.com (Christopher Barker) Date: Thu, 12 Mar 2020 09:26:22 -0700 Subject: [Pythonmac-SIG] Building plans ..... In-Reply-To: References: Message-ID: On Wed, Mar 11, 2020 at 11:48 PM Just van Rossum wrote: > 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'm pretty sure it can. We've moved to PyInstaller, which does work, and I'm'pretty sure that py2app can work with conda's non-Framework build. and it's on conda-forge, so presumably it's worked for at least one person :-) https://anaconda.org/conda-forge/py2app I do recall some issues a while back that have presumably been resolved. > 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. > Actually, perhaps conda would work for you :-) I'm not clear on what gitHub actions allows, but you can certainly use conda on, e.g. TravisCI with OS-X. I've only used it to run tests, but I can't see why you couldn't build a app that way. By the way, it's great to "see" all you from back in the day -- this has been a very quiet list lately! -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: From bergs at janelia.hhmi.org Thu Mar 12 14:42:56 2020 From: bergs at janelia.hhmi.org (Berg, Stuart) Date: Thu, 12 Mar 2020 18:42:56 +0000 Subject: [Pythonmac-SIG] Building plans ..... In-Reply-To: References: Message-ID: <557858D3-6E05-4E41-A56A-1E0D911042A4@janelia.hhmi.org> (I haven?t been following this thread too closely, so sorry in advance if the following is not exactly what you?re looking for.) FWIW, I?ve shipped .app bundles using conda and py2app for years.* I don?t have time to write up a minimal example, but I can provide links to the scripts we use. It?s a little bit of a hack, but it?s not complicated. 1. First, create a conda environment that contains your application and all of its dependencies. 2. Run py2app in ?alias mode?[1]. Alias mode creates a mostly-empty bundle that merely links to an external python installation. It?s intended for development, but we can exploit it for our purposes. On my project, we use a special setup.py script for this.[2] 3. Move the entire conda environment into the .app bundle directory. There?s no need to change the directory structure. 4. Since the .app bundle was pointing to that environment, you need to find/replace the internal links that py2app wrote within your .app bundle. Instead of pointing to the external conda environment, they should point to the now-internal environment (with relative paths, of course). It amounts to a few sed commands and symlinks.[3] Note: Although you moved the conda environment, there should (usually) be no need to replace any paths within the conda environment directory itself. Unless you?re doing something weird, most conda environments use purely relative links internally, and are thus fully relocatable. For example, our application is based on the standard scientific python stack (numpy, pandas, skimage, etc.), with lots of other dependencies, too. If it works for us, it probably works for most people. If you want to see what the final bundle will look like, try downloading the current version of ilastik[4]. (Sorry, it?s a heavy download ? it?s based on a big conda environment, with ~120 packages.) Maybe there are better ways of doing this, but I settled on this method without really needing to understand exactly what py2app is really doing. And plus, it leaves your conda environment completely intact. For instance, you can inspect it with ?conda list -p ilastik.app/Contents/ilastik-release?, or even install additional packages after-the-fact. Best, Stuart *I don?t work on the ilastik project any more, but I?m pretty sure the current team still uses this procedure. [1]: https://py2app.readthedocs.io/en/latest/tutorial.html#development-with-alias-mode [2]: https://git.io/Jv6VG [3]: https://git.io/Jv6Vl [4]: https://www.ilastik.org/download.html From: Pythonmac-SIG on behalf of Christopher Barker Date: Thursday, March 12, 2020 at 12:26 PM To: Just van Rossum Cc: Jack Jansen , Pythonmac-Sig Subject: Re: [Pythonmac-SIG] Building plans ..... On Wed, Mar 11, 2020 at 11:48 PM Just van Rossum > wrote: 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'm pretty sure it can. We've moved to PyInstaller, which does work, and I'm'pretty sure that py2app can work with conda's non-Framework build. and it's on conda-forge, so presumably it's worked for at least one person :-) https://anaconda.org/conda-forge/py2app I do recall some issues a while back that have presumably been resolved. 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. Actually, perhaps conda would work for you :-) I'm not clear on what gitHub actions allows, but you can certainly use conda on, e.g. TravisCI with OS-X. I've only used it to run tests, but I can't see why you couldn't build a app that way. By the way, it's great to "see" all you from back in the day -- this has been a very quiet list lately! -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: From ronaldoussoren at mac.com Thu Mar 12 16:51:44 2020 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 12 Mar 2020 21:51:44 +0100 Subject: [Pythonmac-SIG] Building plans ..... In-Reply-To: References: Message-ID: <21456B42-A5F8-40C7-8C60-C2ACE83E0B93@mac.com> > On 12 Mar 2020, at 07:48, Just van Rossum wrote: > > 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. That?s a limitation in the current version of py2app, but is something that could change if needed. Ronald ? Twitter: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/ From ronaldoussoren at mac.com Thu Mar 12 16:57:32 2020 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 12 Mar 2020 21:57:32 +0100 Subject: [Pythonmac-SIG] Building plans ..... In-Reply-To: References: Message-ID: > On 11 Mar 2020, at 22:34, Jack Jansen wrote: [?] > > - I _think_ that the restriction that a GUI program must be in an App bundle no longer holds, or at least there are ways around it. 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. I?m not sure the limitation is really gone, I still see issues with a number of Cocoa APIs when run from a virtualenv environment, which doesn?t use the Python.app trick, while the same API works with a venv environement (which does use the Python.app trick). One example is >. There is a private API that makes it possible to use GUI libraries outside of an app bundle and that?s used by a number of projects, but I wouldn?t want to use that in Python. Ronald ? Twitter: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pythonchb at gmail.com Fri Mar 13 15:36:59 2020 From: pythonchb at gmail.com (Christopher Barker) Date: Fri, 13 Mar 2020 12:36:59 -0700 Subject: [Pythonmac-SIG] Building plans ..... In-Reply-To: References: Message-ID: > > There is a private API that makes it possible to use GUI libraries outside > of an app bundle and that?s used by a number of projects, but I wouldn?t > want to use that in Python. > Is that what TK is doing? And while probably not good to build it into Python itself, what about building into the GUI toolkits? Do you have a reference to that API? -CHB Ronald > ? > > Twitter: @ronaldoussoren > Blog: https://blog.ronaldoussoren.net/ > > > -- 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: From ronaldoussoren at mac.com Sat Mar 14 09:54:56 2020 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 14 Mar 2020 14:54:56 +0100 Subject: [Pythonmac-SIG] Building plans ..... In-Reply-To: References: Message-ID: > On 13 Mar 2020, at 20:36, Christopher Barker wrote: > > There is a private API that makes it possible to use GUI libraries outside of an app bundle and that?s used by a number of projects, but I wouldn?t want to use that in Python. > > Is that what TK is doing? I don?t know. > > And while probably not good to build it into Python itself, what about building into the GUI toolkits? > > Do you have a reference to that API? I don?t have a reference handy, it has come up before either on this list or the python tracker (years back). IIRC someone found the API by checking how the bundled java VM managed to use GUI APIs without being in an app bundle. Apple is clearly preferring application code packaged as app bundles, and effectively doesn?t care about traditional Unix-y use of macOS. The need for an app bundle when using frameworks is just one example of that. Another example are the issues that keep popping up when trying to use Apple frameworks in child processes after calling os.fork(). Because of this I don?t think it is worthwhile to try to work around this limitation by calling private APIs. That?s even before considering use cases that involve distributing code through the macOS app store. Ronald ? Twitter: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jack.jansen at cwi.nl Sat Mar 14 17:22:18 2020 From: jack.jansen at cwi.nl (Jack Jansen) Date: Sat, 14 Mar 2020 22:22:18 +0100 Subject: [Pythonmac-SIG] Building plans ..... In-Reply-To: References: Message-ID: <90F104F4-C9E7-4750-8701-D54D396AEE0C@cwi.nl> I?m having an incredible amount of deja-vu in this conversation. We seem to be heading down the path of talking about little-documented APIs and such the same way we were doing 15 or 18 years ago?. Christopher, can you explain what the problem is that you?re running into? Why is there a problem with the Mac Python builds having a different structure than other Unix Python builds? Windows Python builds also have a different structure, does the problem occur there as well? From your original post it seems that the problems are with the Anaconda/Conda-forge distribution treating MacOS as ?just another unix distribution?, with the idea that ?Mac GUI compatibility? wouldn?t be too important for the Anaconda users, or could be handled with the pythonw workaround shellscript. But actually ?MacOS-compatible? would be a more accurate term here, because I?m pretty sure there are a whole lot of APIs that have nothing to do with the GUI but won?t work unless you?re running from a bundle: definitely Open Scripting, but probably also audio/video capture, probably anything using keychain like crypto serveices, maybe bluetooth, maybe USB, probably anything using the GPU for computations?.. So basically if you build Python for MacOS as if it is ?just another BSD distribution? then that is indeed what you get: a Python for just another BSD distribution. Hmm, that was a long sentence for what was intended to be the question: ?What is the problem with using a normal MacOS Framework build of Python for Anaconda?? Jack > On 14-Mar-2020, at 14:54 , Ronald Oussoren wrote: > > > >> On 13 Mar 2020, at 20:36, Christopher Barker > wrote: >> >> There is a private API that makes it possible to use GUI libraries outside of an app bundle and that?s used by a number of projects, but I wouldn?t want to use that in Python. >> >> Is that what TK is doing? > > I don?t know. >> >> And while probably not good to build it into Python itself, what about building into the GUI toolkits? >> >> Do you have a reference to that API? > > I don?t have a reference handy, it has come up before either on this list or the python tracker (years back). IIRC someone found the API by checking how the bundled java VM managed to use GUI APIs without being in an app bundle. > > Apple is clearly preferring application code packaged as app bundles, and effectively doesn?t care about traditional Unix-y use of macOS. The need for an app bundle when using frameworks is just one example of that. Another example are the issues that keep popping up when trying to use Apple frameworks in child processes after calling os.fork(). > > Because of this I don?t think it is worthwhile to try to work around this limitation by calling private APIs. That?s even before considering use cases that involve distributing code through the macOS app store. > > Ronald > ? > > Twitter: @ronaldoussoren > Blog: https://blog.ronaldoussoren.net/ -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman -------------- next part -------------- An HTML attachment was scrubbed... URL: From pythonchb at gmail.com Sat Mar 14 18:49:05 2020 From: pythonchb at gmail.com (Christopher Barker) Date: Sat, 14 Mar 2020 15:49:05 -0700 Subject: [Pythonmac-SIG] Building plans ..... In-Reply-To: <90F104F4-C9E7-4750-8701-D54D396AEE0C@cwi.nl> References: <90F104F4-C9E7-4750-8701-D54D396AEE0C@cwi.nl> Message-ID: Jack et al, Yes, lots of deja vu here as well -- I suppose because this hasn't been resolved. > Hmm, that was a long sentence for what was intended to be the question: ?What is the problem with using a normal MacOS Framework build of Python for Anaconda?? I can't really answer this -- I was not part of the original discussion, nor am I in an decision making position now. I'm just a user an contributor to conda-forge that's trying to make things easier. But I think it more or less comes down to what you said: Conda wants to be as similar as possible on all platforms as it can. Yes, there are differences on Windows, but they are keeping those to a minimum, and there is no choice. OS-X, on the other is, as you mentioned, BSD *nix. So doing something very differently there feels gratuitous. And in a practical sense, many folks use OS-X as a development platform, so want to use Python on OS-X in the same way they use it on other *nix systems. I myself have found this to be very helpful for my own work, as well as for teaching. And if you aren't doing any GUI work, then it is nice for the Mad to be "just another *nix". For my part, I develop for the MAc, but only in the context of cross platform tools: I never do anything you can do only on the Mac, and try to do everything in a cross platform way as possible (using wPyrthon for the GUI, for instance). Which is why I want Python, and everything else to work the same . That being said, I'm not sure that this was thought through all that carefully initially, and I haven't seen anyone spell out the reasons for not doing a Framework build other than "Honestly, I think adding the framework will make this more confusing when building things between OS X and Linux" (from https://github.com/conda-forge/python-feedstock/issues/23). But I'll turn around the question: "What is the problem with using a non-framework build for conda on the Mac" (or even outside of conda, e.g.brew or macports) It's unclear to me is what the advantages of a Framework Build are in this context. Other than it being the "Mac way of doing things". It's my impression that Apple simply has not thought out how it should support things like Python -- the whole system is very much designed around "Applications", but the Python interpreter is not an application in the usual sense. But it is also not a library in the usual sense, either. So I'm not sure there IS an obvious right way to support Python on a a Mac. And I understand the idea behind frameworks, and like them. I've never much liked the scattering of things all over the filesystem approach that *nix usually does. But in this case, conda is doing a similar thing, but in a more powerful and flexible way. So cramming a Framework into conda seems gratuitous. As far as I know, the only issue people have had with using a standard Unix build in conda is the whole GUI thing.Jack mentioned a lot of others, essentially interacting the the non-kernel part of the OS, but I haven't heard complaints about that -- maybe because no one's doing that with conda. But the key technical question I'm still not totally clear on is: I understand (vaguely) what having Python running from a App bundle provides -- and these are important features, so we do want to support that. And I I thought that the executable re-directs to one in a bundle could be done independently of the Framework, and the fact that the two is essentially and accident of how they build scripts were set up (and probably easier to do). If I'm correct, then Python could be built to provide an app bundle, but otherwise be just like a "normal" unix build. But what does having Python built as a Framework actually provide, other than making more like the usual Mac setup? As far as I can tell, it would provide no new functionality. In which case, given a choice, for, e.g. a conda build, I'd rather have it be more like the other *nixes than more like other Mac software. In short: as far as I can tell, the only reason to use a Framework build in conda is that it's the only configuration that's already set up to make pythonw in the build scripts, and autoconf is enough of a pain that one wants to make a new configuration. By the way, I chatted with Ned Diely a few years ago about this, and I think he was thinking of moving away form Frameworks for python.org builds, though I don't know if he decided not to make that change, or simply hasn't gotten around to it. -CHB References to Discussions: https://github.com/conda-forge/python-feedstock/issues/23 > Jack > > On 14-Mar-2020, at 14:54 , Ronald Oussoren > wrote: > > > > On 13 Mar 2020, at 20:36, Christopher Barker wrote: > > There is a private API that makes it possible to use GUI libraries outside >> of an app bundle and that?s used by a number of projects, but I wouldn?t >> want to use that in Python. >> > > Is that what TK is doing? > > > I don?t know. > > > And while probably not good to build it into Python itself, what about > building into the GUI toolkits? > > Do you have a reference to that API? > > > I don?t have a reference handy, it has come up before either on this list > or the python tracker (years back). IIRC someone found the API by checking > how the bundled java VM managed to use GUI APIs without being in an app > bundle. > > Apple is clearly preferring application code packaged as app bundles, and > effectively doesn?t care about traditional Unix-y use of macOS. The need > for an app bundle when using frameworks is just one example of that. > Another example are the issues that keep popping up when trying to use > Apple frameworks in child processes after calling os.fork(). > > Because of this I don?t think it is worthwhile to try to work around this > limitation by calling private APIs. That?s even before considering use > cases that involve distributing code through the macOS app store. > > Ronald > ? > > Twitter: @ronaldoussoren > Blog: https://blog.ronaldoussoren.net/ > > > -- > > Jack Jansen, , http://www.cwi.nl/~jack > > If I can't dance I don't want to be part of your revolution -- Emma Goldman > > > > -- 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: From jack.jansen at cwi.nl Sat Mar 14 19:25:01 2020 From: jack.jansen at cwi.nl (Jack Jansen) Date: Sun, 15 Mar 2020 00:25:01 +0100 Subject: [Pythonmac-SIG] Building plans ..... In-Reply-To: References: <90F104F4-C9E7-4750-8701-D54D396AEE0C@cwi.nl> Message-ID: I was tempted to answer this point-by-point, but I think that would lead to a discussion that?ll quickly branch into many different ways and won?t lead to anything. 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. 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). 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. 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. 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. 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 - 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. Jack > On 14-Mar-2020, at 23:49 , Christopher Barker wrote: > > Jack et al, > > Yes, lots of deja vu here as well -- I suppose because this hasn't been resolved. > > > Hmm, that was a long sentence for what was intended to be the question: ?What is the problem with using a normal MacOS Framework build of Python for Anaconda?? > > I can't really answer this -- I was not part of the original discussion, nor am I in an decision making position now. I'm just a user an contributor to conda-forge that's trying to make things easier. > > But I think it more or less comes down to what you said: > > Conda wants to be as similar as possible on all platforms as it can. Yes, there are differences on Windows, but they are keeping those to a minimum, and there is no choice. OS-X, on the other is, as you mentioned, BSD *nix. So doing something very differently there feels gratuitous. > > And in a practical sense, many folks use OS-X as a development platform, so want to use Python on OS-X in the same way they use it on other *nix systems. I myself have found this to be very helpful for my own work, as well as for teaching. And if you aren't doing any GUI work, then it is nice for the Mad to be "just another *nix". For my part, I develop for the MAc, but only in the context of cross platform tools: I never do anything you can do only on the Mac, and try to do everything in a cross platform way as possible (using wPyrthon for the GUI, for instance). Which is why I want Python, and everything else to work the same . > > That being said, I'm not sure that this was thought through all that carefully initially, and I haven't seen anyone spell out the reasons for not doing a Framework build other than > > "Honestly, I think adding the framework will make this more confusing when building things between OS X and Linux" (from https://github.com/conda-forge/python-feedstock/issues/23 ). > > But I'll turn around the question: "What is the problem with using a non-framework build for conda on the Mac" (or even outside of conda, e.g.brew or macports) > > It's unclear to me is what the advantages of a Framework Build are in this context. Other than it being the "Mac way of doing things". It's my impression that Apple simply has not thought out how it should support things like Python -- the whole system is very much designed around "Applications", but the Python interpreter is not an application in the usual sense. But it is also not a library in the usual sense, either. So I'm not sure there IS an obvious right way to support Python on a a Mac. > > And I understand the idea behind frameworks, and like them. I've never much liked the scattering of things all over the filesystem approach that *nix usually does. But in this case, conda is doing a similar thing, but in a more powerful and flexible way. So cramming a Framework into conda seems gratuitous. > > As far as I know, the only issue people have had with using a standard Unix build in conda is the whole GUI thing.Jack mentioned a lot of others, essentially interacting the the non-kernel part of the OS, but I haven't heard complaints about that -- maybe because no one's doing that with conda. > > But the key technical question I'm still not totally clear on is: > > I understand (vaguely) what having Python running from a App bundle provides -- and these are important features, so we do want to support that. > > And I I thought that the executable re-directs to one in a bundle could be done independently of the Framework, and the fact that the two is essentially and accident of how they build scripts were set up (and probably easier to do). If I'm correct, then Python could be built to provide an app bundle, but otherwise be just like a "normal" unix build. > > But what does having Python built as a Framework actually provide, other than making more like the usual Mac setup? As far as I can tell, it would provide no new functionality. In which case, given a choice, for, e.g. a conda build, I'd rather have it be more like the other *nixes than more like other Mac software. > > In short: as far as I can tell, the only reason to use a Framework build in conda is that it's the only configuration that's already set up to make pythonw in the build scripts, and autoconf is enough of a pain that one wants to make a new configuration. > > By the way, I chatted with Ned Diely a few years ago about this, and I think he was thinking of moving away form Frameworks for python.org builds, though I don't know if he decided not to make that change, or simply hasn't gotten around to it. > > -CHB > > References to Discussions: > > https://github.com/conda-forge/python-feedstock/issues/23 > > > > > > Jack > >> On 14-Mar-2020, at 14:54 , Ronald Oussoren > wrote: >> >> >> >>> On 13 Mar 2020, at 20:36, Christopher Barker > wrote: >>> >>> There is a private API that makes it possible to use GUI libraries outside of an app bundle and that?s used by a number of projects, but I wouldn?t want to use that in Python. >>> >>> Is that what TK is doing? >> >> I don?t know. >>> >>> And while probably not good to build it into Python itself, what about building into the GUI toolkits? >>> >>> Do you have a reference to that API? >> >> I don?t have a reference handy, it has come up before either on this list or the python tracker (years back). IIRC someone found the API by checking how the bundled java VM managed to use GUI APIs without being in an app bundle. >> >> Apple is clearly preferring application code packaged as app bundles, and effectively doesn?t care about traditional Unix-y use of macOS. The need for an app bundle when using frameworks is just one example of that. Another example are the issues that keep popping up when trying to use Apple frameworks in child processes after calling os.fork(). >> >> Because of this I don?t think it is worthwhile to try to work around this limitation by calling private APIs. That?s even before considering use cases that involve distributing code through the macOS app store. >> >> Ronald >> ? >> >> Twitter: @ronaldoussoren >> Blog: https://blog.ronaldoussoren.net/ > > -- > Jack Jansen, >, http://www.cwi.nl/~jack > If I can't dance I don't want to be part of your revolution -- Emma Goldman > > > > > > -- > Christopher Barker, PhD > > Python Language Consulting > - Teaching > - Scientific Software Development > - Desktop GUI and Web Development > - wxPython, numpy, scipy, Cython -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman -------------- next part -------------- An HTML attachment was scrubbed... URL: From pythonchb at gmail.com Sat Mar 14 22:11:39 2020 From: pythonchb at gmail.com (Christopher Barker) Date: Sat, 14 Mar 2020 19:11:39 -0700 Subject: [Pythonmac-SIG] Building plans ..... In-Reply-To: References: <90F104F4-C9E7-4750-8701-D54D396AEE0C@cwi.nl> Message-ID: 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 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: From ronaldoussoren at mac.com Sun Mar 15 07:38:58 2020 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sun, 15 Mar 2020 12:38:58 +0100 Subject: [Pythonmac-SIG] Building plans ..... In-Reply-To: References: <90F104F4-C9E7-4750-8701-D54D396AEE0C@cwi.nl> Message-ID: > On 15 Mar 2020, at 03:11, Christopher Barker wrote: > > 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? AFAIK the only difference for this discussion is the ?Python.app? trick, and that can be accomplished outside of a framework build as well (but currently is not). Two other differences: - A framework build is easier to integratie into applications that are built using Xcode (just drop the framework into list of used frameworks) - py2app currently doesn?t work properly with a Unix build Ronald ? Twitter: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/ From pythonchb at gmail.com Sun Mar 15 17:04:44 2020 From: pythonchb at gmail.com (Christopher Barker) Date: Sun, 15 Mar 2020 14:04:44 -0700 Subject: [Pythonmac-SIG] Building plans ..... In-Reply-To: References: <90F104F4-C9E7-4750-8701-D54D396AEE0C@cwi.nl> Message-ID: On Sun, Mar 15, 2020 at 4:39 AM Ronald Oussoren wrote: > AFAIK the only difference for this discussion is the ?Python.app? trick, > and that can be accomplished outside of a framework build as well (but > currently is not). > > Two other differences: > - A framework build is easier to integrate into applications that are > built using Xcode (just drop the framework into list of used frameworks) > When would that come into play? If you are developing an application that embeds the python interpreter? OR if you are using XCode as your IDE for developing a Python App? > - py2app currently doesn?t work properly with a Unix build > But that could be fixed, yes? (And I think PyInstaller already does work with a unix build) I *think* this means that a unix-style build with the python.app "trick" would be appropriate for use in distributions that are otherwise not "mac native" -- e.g. conda, homebrew. As to whether a style build would be OK for the python.org installer, I'm not so sure. That may still be a candidate for a Framework build --it sure does make installation/uninstalling easier than scatter files all over /usr/local. Of course, to make any of this happen, someone with the autoconf skills needs to have the time and motivation to do it. I'm not that person (though who knows how far I would have gotten if I'd spent the time I've spent talking about this actually giving it a try :-) ) So we'll see. Maybe there's no one that both wants this done and has the time and skills to do it -- such is the world of open source. -CHB > Ronald > > ? > > Twitter: @ronaldoussoren > Blog: https://blog.ronaldoussoren.net/ -- 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: From georg.seifert at gmx.de Mon Mar 16 04:09:03 2020 From: georg.seifert at gmx.de (Georg Seifert) Date: Mon, 16 Mar 2020 09:09:03 +0100 Subject: [Pythonmac-SIG] Building plans ..... In-Reply-To: References: <90F104F4-C9E7-4750-8701-D54D396AEE0C@cwi.nl> Message-ID: <499389D6-0B71-41A8-B20E-29AC238FA7CA@gmx.de> > On 15.03.2020, at 22:04, Christopher Barker wrote: > > On Sun, Mar 15, 2020 at 4:39 AM Ronald Oussoren wrote: > AFAIK the only difference for this discussion is the ?Python.app? trick, and that can be accomplished outside of a framework build as well (but currently is not). > > Two other differences: > - A framework build is easier to integrate into applications that are built using Xcode (just drop the framework into list of used frameworks) > When would that come into play? If you are developing an application that embeds the python interpreter? OR if you are using XCode as your IDE for developing a Python App? > I?m using that in my app (written in ObjectiveC) to be able to run python scripts inside the app and to load plugins that are written in python but don?t bring there own python interpreter. Best Georg Seifert From ronaldoussoren at mac.com Mon Mar 16 05:53:25 2020 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 16 Mar 2020 10:53:25 +0100 Subject: [Pythonmac-SIG] Building plans ..... In-Reply-To: References: <90F104F4-C9E7-4750-8701-D54D396AEE0C@cwi.nl> Message-ID: <21F6BD8B-D4C8-46C7-BE8E-71AFF4A8C822@mac.com> > On 15 Mar 2020, at 22:04, Christopher Barker wrote: > > On Sun, Mar 15, 2020 at 4:39 AM Ronald Oussoren > wrote: > AFAIK the only difference for this discussion is the ?Python.app? trick, and that can be accomplished outside of a framework build as well (but currently is not). > > Two other differences: > - A framework build is easier to integrate into applications that are built using Xcode (just drop the framework into list of used frameworks) > When would that come into play? If you are developing an application that embeds the python interpreter? OR if you are using XCode as your IDE for developing a Python App? That?s something you can use to embed Python into an ObjC app. > > - py2app currently doesn?t work properly with a Unix build > > But that could be fixed, yes? (And I think PyInstaller already does work with a unix build) Sure. Fixing this isn?t too hard, although it will take more time than I?d like due to the way the code is structured. > > I *think* this means that a unix-style build with the python.app "trick" would be appropriate for use in distributions that are otherwise not "mac native" -- e.g. conda, homebrew. > > As to whether a style build would be OK for the python.org installer, I'm not so sure. That may still be a candidate for a Framework build --it sure does make installation/uninstalling easier than scatter files all over /usr/local. Right. That?s an important consideration given that macOS doesn?t have a proper native package manager, just an installer. > > Of course, to make any of this happen, someone with the autoconf skills needs to have the time and motivation to do it. I'm not that person (though who knows how far I would have gotten if I'd spent the time I've spent talking about this actually giving it a try :-) ) > > So we'll see. Maybe there's no one that both wants this done and has the time and skills to do it -- such is the world of open source. Agreed. In the end everyone working on Python is a volunteer. Ronald ? Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pythonchb at gmail.com Mon Mar 16 11:57:02 2020 From: pythonchb at gmail.com (Christopher Barker) Date: Mon, 16 Mar 2020 08:57:02 -0700 Subject: [Pythonmac-SIG] Building plans ..... In-Reply-To: <499389D6-0B71-41A8-B20E-29AC238FA7CA@gmx.de> References: <90F104F4-C9E7-4750-8701-D54D396AEE0C@cwi.nl> <499389D6-0B71-41A8-B20E-29AC238FA7CA@gmx.de> Message-ID: On Mon, Mar 16, 2020 at 1:09 AM Georg Seifert wrote: > > - A framework build is easier to integrate into applications that are > built using Xcode (just drop the framework into list of used frameworks) > > When would that come into play? If you are developing an application > that embeds the python interpreter? OR if you are using XCode as your IDE > for developing a Python App? > > > I?m using that in my app (written in ObjectiveC) to be able to run python > scripts inside the app and to load plugins that are written in python but > don?t bring there own python interpreter. > Perfect -- and that's using Python more as a "library". So providing a Framework build is a good thing for these uses. Though I wonder if there's a need for a pre-built one with an installer --wouldn't folks using XCode be able to built it themselves? But either way, this isn't a use case for conda, or brew or .... Also, there's no reason that a "PythonFramework" couldn't be a separate package in conda -- you just wouldn't want to have all the other Python-y stuff depending on it. If you are embedding the interpreter, you are managing all the the dependencies anyway. Now someone just needs the time to do it :-( -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: From jack.jansen at cwi.nl Mon Mar 16 18:54:58 2020 From: jack.jansen at cwi.nl (Jack Jansen) Date: Mon, 16 Mar 2020 23:54:58 +0100 Subject: [Pythonmac-SIG] Building plans ..... In-Reply-To: References: <90F104F4-C9E7-4750-8701-D54D396AEE0C@cwi.nl> Message-ID: > > 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. So how does conda handle things that must be installed in ?special? locations on some platforms? For example, if you install some package that contains a kernel driver, undoubtedly on windows this?ll have to go somewhere deep down in c:\system32 or something. Because in a way Python on the mac (if you want to use a framework/app/bundle Python) is like that: it has some platform-specific installation requirements (that bits of it go into /Library/Frameworks and other bits in /Application), and in the end you setup a few symlinks in the conda bin directory (or the conda per-environment bin directory, or however that works) and for a conda user the situation will be exactly the same on Mac as on Linux?.. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman -------------- next part -------------- An HTML attachment was scrubbed... URL: From pythonchb at gmail.com Mon Mar 16 21:35:21 2020 From: pythonchb at gmail.com (Christopher Barker) Date: Mon, 16 Mar 2020 18:35:21 -0700 Subject: [Pythonmac-SIG] Building plans ..... In-Reply-To: References: <90F104F4-C9E7-4750-8701-D54D396AEE0C@cwi.nl> Message-ID: On Mon, Mar 16, 2020 at 3:55 PM Jack Jansen wrote: 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 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. So how does conda handle things that must be installed in ?special? > locations on some platforms? For example, if you install some package that > contains a kernel driver, undoubtedly on windows this?ll have to go > somewhere deep down in c:\system32 or something. > I expect that answer is "it doesn't" -- it's really not intended to support things like kernel drivers. The point of conda is not just package management, but the ability to create isolated environments, with specific versions of various inter-dependent packages. An environment is essentially a directory tree with a loto f familiar (to the *nix folks, anyway) directories. Here's what's in my primary working environment, for example: $ ls bin phrasebooks conda-meta plugins doc qml etc qsci include resources lib sbin libexec share man ssl mkspecs translations When you "activate" an environment, it sets up a bunch of environment variables so that those "Versions" are found first. Here's $PATH by my primarily working environment (called py3) is activated: $ echo $PATH /Users/chris.barker/miniconda3/envs/py3/bin:/Library/TeX/texbin:/Users/chris.barker/miniconda3/condabin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/sbin It prepended the bin dir from the Environment on there. It does similar things to all the other env variables. Because in a way Python on the mac (if you want to use a > framework/app/bundle Python) is like that: it has some platform-specific > installation requirements (that bits of it go into /Library/Frameworks and > other bits in /Application), and in the end you setup a few symlinks in the > conda bin directory (or the conda per-environment bin directory, or however > that works) and for a conda user the situation will be exactly the same on > Mac as on Linux?.. > So yes, you could install the entire Framework inside the environment, and then have the various links to the "expected" places inside that environment (conda uses relative paths wherever possible, so it wouldn't be hard). And probably, it would end up looking just like a *nux install as far as everything else is concerned, except for that extra Framework thing in there somewhere that could be ignored. I'm not sure why the conda folks decided not to do that in the first place, but they didn't, and no one seems to want to do it now. I suppose I could set it up and submit a PR and see what folks think, but the big question is: what does a Framework Build by conda? ANd I think the answer is nothing, except that we already know how to build the pythonw executable that way. -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: From barry at barrys-emacs.org Tue Mar 17 17:28:29 2020 From: barry at barrys-emacs.org (Barry Scott) Date: Tue, 17 Mar 2020 21:28:29 +0000 Subject: [Pythonmac-SIG] Building plans ..... In-Reply-To: References: <90F104F4-C9E7-4750-8701-D54D396AEE0C@cwi.nl> Message-ID: > On 16 Mar 2020, at 22:54, Jack Jansen wrote: > > >> >> 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. > > > So how does conda handle things that must be installed in ?special? locations on some platforms? For example, if you install some package that contains a kernel driver, undoubtedly on windows this?ll have to go somewhere deep down in c:\system32 or something. Does this force the use of conda on macOS python users? Or is it just asking for a build option that is conda friendly? I have been happy use the python.org builds and py2app + PyQt5. Barry > > Because in a way Python on the mac (if you want to use a framework/app/bundle Python) is like that: it has some platform-specific installation requirements (that bits of it go into /Library/Frameworks and other bits in /Application), and in the end you setup a few symlinks in the conda bin directory (or the conda per-environment bin directory, or however that works) and for a conda user the situation will be exactly the same on Mac as on Linux?.. > -- > Jack Jansen, >, http://www.cwi.nl/~jack > If I can't dance I don't want to be part of your revolution -- Emma Goldman > > > > _______________________________________________ > 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: From pythonchb at gmail.com Wed Mar 18 16:58:10 2020 From: pythonchb at gmail.com (Christopher Barker) Date: Wed, 18 Mar 2020 13:58:10 -0700 Subject: [Pythonmac-SIG] Building plans ..... In-Reply-To: References: <90F104F4-C9E7-4750-8701-D54D396AEE0C@cwi.nl> Message-ID: > Does this force the use of conda on macOS python users? Absolutely not. > Or is it just asking for a build option that is conda friendly? > That?s it exactly. I would think it would be friendly to other use cases, but the default Python.org builds are a different use case, and should be built in a way that?s appropriate for those users. I have been happy use the python.org builds and py2app + PyQt5. > Exactly? I?m not suggesting anything change for folks like you. -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: