Sorry -- looks like I took this offline by accident. I really prefer mailing list to be set with reply-to to the list....
So I"ll leave more the the thread than I usually do. If your mail client collapses old quotes, you may want to expand them... On Thu, Dec 15, 2016 at 9:27 AM, Ronald Oussoren <ronaldousso...@mac.com> wrote: > > On 15 Dec 2016, at 17:34, Christopher Barker <python...@gmail.com> wrote: > > > On Thu, Dec 15, 2016 at 12:59 AM Ronald Oussoren <ronaldousso...@mac.com> > wrote: > >> >> > Frameworks have the nice feature that everything related to the >> framework is stored in a single location, with proscribed location for that >> location. >> >> Yeah, I really like the approach -- the *nix habit of scattering stuff >> all over the place is really ugly. >> >> > This is especially useful when doing side-by-side installation of >> Python 2 and Python 3, those naturally get different locations for their >> binaries which avoids conflicts when installing scripts into both of them. >> >> >> In the conda case -- conda is managing the whole environment for you >> instead -- kinda like a monster Framework, I suppose, >> >> Putting a Framework inside a Conda environment is kinda weird-- and I >> think the conda folks wanted to keep things as consistent across platforms >> as possible. >> > > How does conda deal with having both Python2 and Python3? Or is that out > of scope? From what I’ve seen and heard at conferences the scientific > users of python seem to move to Python 3 at a high speed. > > conda controls python itself in isolated environments, so a given environment can be python 2 or python 3. and you can have any number of environments hanging around. It doesn't support python2 and pyton3 is the same environment though -- which is a pity. > >> > Building python.app + the launcher script outside of a framework should >> be easy, but I don’t understand why you’d want to do so as this will give >> you yet another way to deploy python on macOS. >> >> There are already multiple ways to deploy python on macOS ;-) >> > > I know, but that’s no reason to make it worse. > FAir enough -- but having an easy way to build a non-framework python that supports GUIs would be nice -- and then all teh "unixey" builds could use that -- so no net increase ;-) > And in Conda's case, there are good reasons for it. But having the python > binary in conda work for GUI apps would be a very good thing. > > I have never gotten an answer from the conda folks as to why they did the > app bundle the way they did -- I suspect it was simply the first way they > came up with that seemed to work. > > And apparently there are only a few people trying to use conda for GUI > apps on the Mac -- no not much motivation for change. ( and what they have > mostly works) > > > > BTW. In the longer run I’d love to see a binary distribution that’s just > a Python.app with everything bundled inside, that would reduce the friction > of installing python even further. > > > Installing Python isn't where the real friction is -- it's installing > third party packages that provides the friction. > > A GUI wrapper around pip et al might be a nice thing, though -- so folks > could have a Mac-ish way to deal with dependencies. > > > The main launcher of the app bundle could be a launcher for IDLE, > possibly enhanced with a menu for installing symlinks to bundled > executables/scripts into /usr/local/bin. > > I don't think that's a good idea -- IDLE has pretty limited usefulness. > I'd rather see Python installed on such a way as to enable smooth command > line usage, other IDEs, etc. > That shouldn’t be a problem, it would basically switch the current setup > around: we now have a Python.framework containing a Python.app, and would > end up with a Python.app containing a Python.framework (or a shared library > install, doesn’t really matter). Other tools could still use the python > installation inside the app bundle. > I guess a few well-placed symlinks would make is all work fine. I mentioned IDLE because that is the primary GUI shipped with the CPython > distribution and a GUI that’s there is better than one that isn’t ;-). > well, yes and no -- I'd rather folks would need to choose an IDE -- an easy way to choose IDLE would be good, though. > Which burying it an app might be fine for -- much like the framework > build. But the "Python" app could be a GUI tool for managing the python > install -- the symlink thing, package management, etc. maybe a front end > for py2app? an easy way to bring up a (iPython?) console…. > If only I had the time to spend serious time on this… I think a > Python.app with a useful GUI could be a worthwhile project, but > realistically speaking I don’t have time to work on this. > I know the feeling -- not much general interest in the Mac as platform at all :-( -- except and a version of Unix. I have a hard time keeping my current projects alive, I’m currently working > my way through a couple of years of backlog in the py2app tracker and > that’s just fixing smallish issues with the current code base (recipes that > no longer work, supporting newer versions of python). Py2app itself also > needs some serious attention: the code is a distutils extension and as such > is basically untestable using unittests. Furthermore distutils/setupools > extensions themselves are more of a legacy feature, the world is slowly > moving away from setuptools. I have some vague plans about the redesign of > the py2app interface using a structured configuration format > (YAML/TOML/JSON/…), but haven’t had time yet to make those plans more > concrete. > For what it's worth, I'd rather see this than a MacPython GUI ... > > >> Is there an easy way to have one App bundle with multiple "launchers". Or >> is that a Franework with multiple apps…. >> > > The application bundle has 1 main entry point that’s launched when you > start the app. The app could contain embedded application bundles for other > functionality, the “Xcode -> Open Developer Tool” menu in Xcode is an > example of that. > > ahh -- so our MacPython GUI could launch IDLE, or an iPython console (Or notebook), or ... slick! Now we just need someone to write it ..... >> In practice though, pretty much anyone doing real work with Python is >> going to need the command line at some point -- so I always just bite the >> bullet and start newbies off that way. >> > > The unix command-line is too powerful as a toolset to ignore, but IMHO it > should be possible to have a useful environment that doesn’t need the > command-line to do useful work (says someone who tends to live on the > command-line, and most of the time doesn’t even use a graphical text > editor). > > Anyway -- thanks for the PyObj updated an wheels! -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@python.org https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG