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

MinRK benjaminrk at gmail.com
Tue Dec 10 01:51:49 EST 2013


On Mon, Dec 9, 2013 at 5:18 PM, Chris Barker <chris.barker at noaa.gov> wrote:

> On Mon, Dec 9, 2013 at 3:43 PM, Paul Moore <p.f.moore at gmail.com> wrote:
>
>>  we need to be able to express constraints people need.
>>  So we need to make sure we understand those constraints.
>>
>>  Obviously
>> pip/wheel would never implement something this specific, but I *could*
>> see a conditional something like "check the value of a variable
>> imported from a module on the installation target machine" as being
>> worth discussion.
>
>
> as you pointed out -- this is essentially a platform check.
>
> So we could do OK if there was a way to express paltform-specific
> dependencies to pip. so that, for instance, "pip install ipython", would
> get readline as a dependency on OS-X, but not on linux. That would be
> pretty simple, solve this problem and probably be useful elsewhere.
>

It is not jut a platform check - depending on an external readline package
is the right thing to do on OS X System Python and Python.org, but not on
macports, conda, or manually compiled Python linked against readline. A
simple platform check is insufficient, libedit must be specifically checked
for before expressing a dependency on the readline package. In the very
brief period that it was an unconditional dependency on OS X, we already
had reports of failed installs due to failed compilation of the readline
module on a Python where it wasn't needed, so that's just not acceptable.


>
> However, in this case, a I tend to agree with what we think Guido thinks (
> ;-) ), that overriding a build-in module is a bad idea, pyreadline really
> should use a different name, and then ipython could simply depend on that.
> Granted, that would mean duplicate functionality, but if readline is
> somewhat broken somewhere, maybe not so bad to be consistent.
>

Regardless of where we land on the rest, this is definitely true - renaming
the installed module is the easiest way to  solve the runtime issue, so
that's what we are doing now, and should have done as soon as we realized
that we were depending on gross easy_install behavior that pip "fixes". But
the condition of the dependency is still more specific than simply
`sys.platform=='darwin'`.

> overriding a build-in module is a bad idea

By the way on this one, Apple has made this extra complicated: 10.9 ships
with numpy, scipy, and matplotlib (among other things - setuptools,
twisted, etc.). It ships these in an Extras directory, which is, as far as
`sys.path` priority is concerned, part of the stdlib. That means that you
will not be able to `pip install` any of those packages with System Python
on OS X 10.9.  Or, more precisely, pip will install them, but after the
successful install, they will never be importable. If you want to install
or upgrade numpy, scipy, or setuptools on OS X, you must do one (or more)
of:

1. use virtualenv
2. use non-System Python
3. use easy_install
4. use manual setup.py install (with setuptools)
5. use `pip install -e`, which *does* appear ahead of stdlib, unlike
regular `pip install`.

Note that this includes setuptools, so you need to make sure that pip is
never in charge of updating setuptools, because it will result in
*removing* importable setuptools, and you will have to start from scratch
bootstrapping setuptools from ez_setup.py.

-MinRK


> -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
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131209/28e20430/attachment.html>


More information about the IPython-dev mailing list