[Pythonmac-SIG] [Pyobjc-dev] PyObjC and macOS 10.12 (Sierra)

[Christopher Barker]

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 <ronaldoussoren at mac.com>
wrote:

>
> On 15 Dec 2016, at 17:34, Christopher Barker <pythonchb at gmail.com> wrote:
>
>
> On Thu, Dec 15, 2016 at 12:59 AM Ronald Oussoren <ronaldoussoren at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20161215/1caa2a8e/attachment-0001.html>