Re: [Pythonmac-SIG] Building plans .....

[Christopher Barker]

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
binphrasebooks
conda-meta plugins
docqml
etcqsci
includeresources
libsbin
libexecshare
manssl
mkspecstranslations

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
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Building plans .....

[Jack Jansen]

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



___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Building plans .....

[Christopher Barker]

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
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Building plans .....

[Ronald Oussoren via Pythonmac-SIG]

> 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/___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Building plans .....

[Georg Seifert]

> 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

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG