[IPython-dev] iPython binary wheels for OS-X

[Chris Barker]

On Tue, Dec 10, 2013 at 10:36 AM, MinRK <benjaminrk at gmail.com> wrote:

> On Tue, Dec 10, 2013 at 8:03 AM, Chris Barker - NOAA Federal <
> chris.barker at noaa.gov> wrote:
>
>> Or should fix -- people shouldn't be messing with the system python
>> anyway,
>>
>
> This is what's so frustrating - the System Python isn't touched at all,
> nothing is "messed with", unless by "messed with", you just mean "used at
> all".
>

The problem is that you can do a lot with the system python without
"messing with" it, but you can't do everything with it. We've been dealing
with this for years and discussed it many times on the python-mac SIG, and
have always come to the conclusion that it was better to recommend  that
people leave the system one alone, and start our with an alternative python
installation and go from there.

This is much easier for users than encouraging them to use the system
python, get a bunch of stuff installed and working with it, then hit a
roadblock and have to start all over again with a new python install.

Also -- it's hard enough to get package maintainers to build binaries --
having one python build to support is a really good idea, and the Apple one
can can't be used for everything, so it not a good option.

imagine it is feasible there. It seems absurd that Python's packaging and
> import system is so bad that installing a duplicate Python is the only
> answer to *completely nondestructive installation of a package*.
>

well, with virtualenv these days, *maybe* we could recommend it, but I'm
pretty wary -- and that still wouldn't let you re-distribute with py2app or
upgrade python itself.

Would you say that nobody should be messing with system Python on Linux by
> doing a `--user` install of a package, or even a regular system-wide pip
> install?
>

It's been a while for me,  but Back in the Day, RedHat was very sensitive
to touching the system python -- even worse, you couldn't have another
"python" on your path at all!

But another difference there is that for the most part, the distros are
upgrading python itself as bug-fix releases come out, and don't have the
same restrictions on re-distribution.

On linux, system `dist-packages` are lower priority than `site-packages`. I
> don't think there is anything different about Extras on OS X.
>

on my OS-X 10.7 system, Apple Python 2.7.1 (note only *.*.1 -- hasn't been
upgraded in a long time!):

/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python

is before

 /Library/Python/2.7/site-packages

and there is a lot of Apple installed stuff in Extras.

So you'd need to replace stuff in Extras if you  wanted it to be found,
unless you are messing with sys.path.

Also -- still a bit confused about what Extras is supposed to be, but it
seems to me that any time you install a newer version of a package such
that it can be found without messing with sys.path, then any script using
that python will be subject to that upgrade -- that is "messing with" the
system python.

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20140117/a0498372/attachment.html>