iPython binary wheels for OS-X

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

iPython binary wheels for OS-X

Chris Barker
Hi folks,

If you are not on the distutils-sig list, and you probably aren't, we've been moving forward with trying to get the new binary wheel format better used and tested.

In this spirit, I've built some binary wheels for iPython and its dependencies. Ralf Gommers was nice enough to put them up on source forge for all to see and test. Here's his note to the numpy list:

At http://sourceforge.net/projects/numpy/files/wheels_to_test/ you can find a set of wheels, for numpy, scipy and ipython plus its dependencies. These are for the following configuration only:
  - OSX >= 10.6
  - Python 2.7 32/64-bit from python.org

It would be great if OS X users could test these. We're interested in whether these wheels work, and also if you run into any issues installing wheels. Since (a) I'm not really sure myself what the recommended and most robust way is to install wheels, and (b) it's interesting to see if the docs and usability of pip/wheel are ready for prime time, I'm not going to give the commands to execute but instead link to the relevant docs:

http://www.pip-installer.org/en/latest/index.html
http://python-packaging-user-guide.readthedocs.org/en/latest/
http://wheel.readthedocs.org/en/latest/index.html

Please try this out and share your experience.
 

You probably want to use ipython[all] to get all the stuff that the notebook needs...

One thing I noticed is that readline is NOT listed as a dependency -- strictly speaking, it's not, but you really do want it, particualry on OS-X. Maybe we should add it. Also, the warnign about readline in ipython says that "pip install" does not work right, but it's working fine for me -- outdated note? or am I just lucky?

A tiny bit of background:

I'm hoping for wheel to get better supported in general, it would be really nice if folks could "pip install" more stuff. And my focus in on OS-X users that aren't unix geeks at the moment. 

But in particular, at the moment I am teaching a general intro to python class: no numpy,scipy, etc....

But iPython, as we all know, is awesome, so I've been using it in demos, and want my students to be able to use it to.

I've told Windows users to go to the Gohlke repo to get it.

Linux users can either use their system package maager, or probably pip intstall it.

Mac users that aren't using HomeBrew or MacPorts are a bit stuck.

The iPython web page suggests that they should go get Anocanda or Canopy -- which may be the best way to go if you want the whole scipy stack, but if you want iPython, and also want a system compatible with virtualenv, all the web development packages, and desktop stuff like wxPython, etc, it may not be the way to go. In particular, I had a couple students install Anaconda, and then find themselves stuck trying to use wxPython. I've had a bunch of emails on the distuitls list, and with Travis O, and maybe the future will be better compatibility with Anocanda and other systems, but nevertheless, I think it's a good idea to have and easy way for folks to "just get ipython" :

pip --use_wheel ipython[all]

and presto! have it ready to go.

By the way, the wheels themselves are trivially easy to build, once setup.py build works....

-Chris

PS: we should do Windows,too.....but I only have an old copy of XP on an old netbook, so that probably won't be me!

PPS: and py3....

--

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

[hidden email]


_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: iPython binary wheels for OS-X

MinRK
On Sun, Dec 8, 2013 at 3:06 PM, Chris Barker <[hidden email]> wrote:
>
> Hi folks,
>
> If you are not on the distutils-sig list, and you probably aren't, we've been moving forward with trying to get the new binary wheel format better used and tested.
>
> In this spirit, I've built some binary wheels for iPython and its dependencies. Ralf Gommers was nice enough to put them up on source forge for all to see and test. Here's his note to the numpy list:
>
>> At http://sourceforge.net/projects/numpy/files/wheels_to_test/ you can find a set of wheels, for numpy, scipy and ipython plus its dependencies. These are for the following configuration only:
>>   - OSX >= 10.6
>>   - Python 2.7 32/64-bit from python.org
>>
>> It would be great if OS X users could test these. We're interested in whether these wheels work, and also if you run into any issues installing wheels. Since (a) I'm not really sure myself what the recommended and most robust way is to install wheels, and (b) it's interesting to see if the docs and usability of pip/wheel are ready for prime time, I'm not going to give the commands to execute but instead link to the relevant docs:
>>
>> http://www.pip-installer.org/en/latest/index.html
>> http://python-packaging-user-guide.readthedocs.org/en/latest/
>> http://wheel.readthedocs.org/en/latest/index.html
>>
>> Please try this out and share your experience.
>
>  
>
> You probably want to use ipython[all] to get all the stuff that the notebook needs...
>
> One thing I noticed is that readline is NOT listed as a dependency -- strictly speaking, it's not, but you really do want it, particualry on OS-X. Maybe we should add it. Also, the warnign about readline in ipython says that "pip install" does not work right, but it's working fine for me -- outdated note? or am I just lucky?

readline should be a dependency on OS X, I know it used to be. The logic may have gotten confused a bit.

The warning is still correct, and I still recommend that all OS X users easy_install (not pip) readline. The issue has been discussed in various places (here is one), but it's a sys.path priority issue. Nobody should ever use pip to install readline. But since people still do, incorrectly believing that pip is actually a replacement for easy_install, IPython has an unadvertised hack to make the normally never importable pip installed readline available, as long as IPython is the first to try to import it.

>
> A tiny bit of background:
>
> I'm hoping for wheel to get better supported in general, it would be really nice if folks could "pip install" more stuff. And my focus in on OS-X users that aren't unix geeks at the moment.
>
> But in particular, at the moment I am teaching a general intro to python class: no numpy,scipy, etc....
>
> But iPython, as we all know, is awesome, so I've been using it in demos, and want my students to be able to use it to.
>
> I've told Windows users to go to the Gohlke repo to get it.
>
> Linux users can either use their system package maager, or probably pip intstall it.
>
> Mac users that aren't using HomeBrew or MacPorts are a bit stuck.
>
> The iPython web page suggests that they should go get Anocanda or Canopy -- which may be the best way to go if you want the whole scipy stack, but if you want iPython, and also want a system compatible with virtualenv, all the web development packages, and desktop stuff like wxPython, etc, it may not be the way to go. In particular, I had a couple students install Anaconda, and then find themselves stuck trying to use wxPython. I've had a bunch of emails on the distuitls list, and with Travis O, and maybe the future will be better compatibility with Anocanda and other systems, but nevertheless, I think it's a good idea to have and easy way for folks to "just get ipython" :
>
> pip --use_wheel ipython[all]
>
> and presto! have it ready to go.

pyzmq, the only binary dependency of IPython, has had wheels on OS X and Windows for a few releases now, so `pip install --use-wheel ipython[all]` should already work on a fresh OS X system without any help (after installing pip and wheel, of course).

>
> By the way, the wheels themselves are trivially easy to build, once setup.py build works....

Yes, they are easy to build for yourself, and are typically reusable for machines sufficiently similar to yours. But it's a lot more delicate to be sure that the eggs actually self-identify correctly, and will be properly ignored on systems where they won't work. This is why IPython has decided against building (official) wheel bdists for at least another release.

I am 100% behind a semi-not-so-official-wheels-for-osx effort a la Gohlke, that's actually why I started publishing my own wheels. But honestly,
in a student environment, I would recommend anaconda (or just conda).

-MinRK

>
> -Chris
>
> PS: we should do Windows,too.....but I only have an old copy of XP on an old netbook, so that probably won't be me!
>
> PPS: and py3....
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R            <a href="tel:%28206%29%20526-6959" value="+12065266959" target="_blank">(206) 526-6959   voice
> 7600 Sand Point Way NE   <a href="tel:%28206%29%20526-6329" value="+12065266329" target="_blank">(206) 526-6329   fax
> Seattle, WA  98115       <a href="tel:%28206%29%20526-6317" value="+12065266317" target="_blank">(206) 526-6317   main reception
>
> [hidden email]
>
>
> _______________________________________________
> IPython-dev mailing list
> [hidden email]
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>

_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: iPython binary wheels for OS-X

Chris Barker
On Sun, Dec 8, 2013 at 9:24 PM, MinRK <[hidden email]> wrote:
 
readline should be a dependency on OS X, I know it used to be. The logic may have gotten confused a bit.

Does pip support a way to do platform-dependent dependencies? Anyway, pip isn't lookeing for it for me. Frankly, no biggie, auto-dependencies are nice, but I don't mind hand-installing something if ti's easy to install.

But wouldn't it be a dependency o Windows, too?
 
The warning is still correct, and I still recommend that all OS X users easy_install (not pip) readline. The issue has been discussed in various places (here is one), but it's a sys.path priority issue. Nobody should ever use pip to install readline. But since people still do, incorrectly believing that pip is actually a replacement for easy_install,

well, I'm pretty sure that is the goal -- really we don't want to almost the same package installer for Python....


 
IPython has an unadvertised hack to make the normally never importable pip installed readline available, as long as IPython is the first to try to import it.

hmm -- pretty cool, and it sure works for me, but a bit fragile ;-)
 
pyzmq, the only binary dependency of IPython, has had wheels on OS X and Windows for a few releases now, so `pip install --use-wheel ipython[all]` should already work on a fresh OS X system without any help (after installing pip and wheel, of course).


It sure would be nice if that were advertised a bit.....I really did loo, but of course I never thought just try it!

>
> By the way, the wheels themselves are trivially easy to build, once setup.py build works....

Yes, they are easy to build for yourself, and are typically reusable for machines sufficiently similar to yours. But it's a lot more delicate to be sure that the eggs actually self-identify correctly, and will be properly ignored on systems where they won't work. This is why IPython has decided against building (official) wheel bdists for at least another release.

There has been a lot of discussion about this on the distutils list, and I _think_ there is more or less a consensus that we should put binary wheels up on PyPi for the python.org builds for Windows and OS-X. Those should work at this point (sse issues asside for numpy/scipy)

Doing it for Macports or HomeBrew, or what have you is pretty much alost cause, but that's not a big deal -- those are systems designed for people to compile there own stuff anyway. similar for Linux.

So what's missing?

And, as you say, zmq is really the only one we need anyway, what exactly is iPython not doing?

 
I am 100% behind a semi-not-so-official-wheels-for-osx effort a la Gohlke, that's actually why I started publishing my own wheels.

nice! but not that useful if we don't get the word out.
 
But honestly,
in a student environment, I would recommend anaconda (or just conda).

non starter for now -- Again, these are NOT scipy stack classes -- and I do want wx, and the guy teaching the next class on web development really wants virtualenv.

Anocanda does not work (for now) on those.

Anyway -- I feel very strongly that we should play well with the rest of the Python word, and that mean pip and wheels ... and we really can do it now.

I guess I need to do a pull request for the "installing" page of the iPython web sire next...

-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

[hidden email]

_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: iPython binary wheels for OS-X

Matthias Bussonnier
Hi, 

Also of interest, 

previous discussion about that:

I'm sure there are other threads somewhere. 
--
M

Le 9 déc. 2013 à 07:02, Chris Barker a écrit :

On Sun, Dec 8, 2013 at 9:24 PM, MinRK <[hidden email]> wrote:
 
readline should be a dependency on OS X, I know it used to be. The logic may have gotten confused a bit.

Does pip support a way to do platform-dependent dependencies? Anyway, pip isn't lookeing for it for me. Frankly, no biggie, auto-dependencies are nice, but I don't mind hand-installing something if ti's easy to install.

But wouldn't it be a dependency o Windows, too?
 
The warning is still correct, and I still recommend that all OS X users easy_install (not pip) readline. The issue has been discussed in various places (here is one), but it's a sys.path priority issue. Nobody should ever use pip to install readline. But since people still do, incorrectly believing that pip is actually a replacement for easy_install,

well, I'm pretty sure that is the goal -- really we don't want to almost the same package installer for Python....


 
IPython has an unadvertised hack to make the normally never importable pip installed readline available, as long as IPython is the first to try to import it.

hmm -- pretty cool, and it sure works for me, but a bit fragile ;-)
 
pyzmq, the only binary dependency of IPython, has had wheels on OS X and Windows for a few releases now, so `pip install --use-wheel ipython[all]` should already work on a fresh OS X system without any help (after installing pip and wheel, of course).


It sure would be nice if that were advertised a bit.....I really did loo, but of course I never thought just try it!

>
> By the way, the wheels themselves are trivially easy to build, once setup.py build works....

Yes, they are easy to build for yourself, and are typically reusable for machines sufficiently similar to yours. But it's a lot more delicate to be sure that the eggs actually self-identify correctly, and will be properly ignored on systems where they won't work. This is why IPython has decided against building (official) wheel bdists for at least another release.

There has been a lot of discussion about this on the distutils list, and I _think_ there is more or less a consensus that we should put binary wheels up on PyPi for the python.org builds for Windows and OS-X. Those should work at this point (sse issues asside for numpy/scipy)

Doing it for Macports or HomeBrew, or what have you is pretty much alost cause, but that's not a big deal -- those are systems designed for people to compile there own stuff anyway. similar for Linux.

So what's missing?

And, as you say, zmq is really the only one we need anyway, what exactly is iPython not doing?

 
I am 100% behind a semi-not-so-official-wheels-for-osx effort a la Gohlke, that's actually why I started publishing my own wheels.

nice! but not that useful if we don't get the word out.
 
But honestly,
in a student environment, I would recommend anaconda (or just conda).

non starter for now -- Again, these are NOT scipy stack classes -- and I do want wx, and the guy teaching the next class on web development really wants virtualenv.

Anocanda does not work (for now) on those.

Anyway -- I feel very strongly that we should play well with the rest of the Python word, and that mean pip and wheels ... and we really can do it now.

I guess I need to do a pull request for the "installing" page of the iPython web sire next...

-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

[hidden email]
_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev


_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: iPython binary wheels for OS-X

Aaron Meurer
In reply to this post by Chris Barker
On Sun, Dec 8, 2013 at 11:02 PM, Chris Barker <[hidden email]> wrote:

> On Sun, Dec 8, 2013 at 9:24 PM, MinRK <[hidden email]> wrote:
>
>>
>> readline should be a dependency on OS X, I know it used to be. The logic
>> may have gotten confused a bit.
>
>
> Does pip support a way to do platform-dependent dependencies? Anyway, pip
> isn't lookeing for it for me. Frankly, no biggie, auto-dependencies are
> nice, but I don't mind hand-installing something if ti's easy to install.
>
> But wouldn't it be a dependency o Windows, too?
>
>>
>> The warning is still correct, and I still recommend that all OS X users
>> easy_install (not pip) readline. The issue has been discussed in various
>> places (here is one), but it's a sys.path priority issue. Nobody should ever
>> use pip to install readline. But since people still do, incorrectly
>> believing that pip is actually a replacement for easy_install,
>
>
> well, I'm pretty sure that is the goal -- really we don't want to almost the
> same package installer for Python....

What's the reason you can't pip install readline? Is it because pip
insists on compiling it? If so, wouldn't wheels solve this issue?

>
>
>
>>
>> IPython has an unadvertised hack to make the normally never importable pip
>> installed readline available, as long as IPython is the first to try to
>> import it.
>>
> hmm -- pretty cool, and it sure works for me, but a bit fragile ;-)
>
>>
>> pyzmq, the only binary dependency of IPython, has had wheels on OS X and
>> Windows for a few releases now, so `pip install --use-wheel ipython[all]`
>> should already work on a fresh OS X system without any help (after
>> installing pip and wheel, of course).
>>
>
> It sure would be nice if that were advertised a bit.....I really did loo,
> but of course I never thought just try it!
>
>>
>>
>> > By the way, the wheels themselves are trivially easy to build, once
>> > setup.py build works....
>>
>> Yes, they are easy to build for yourself, and are typically reusable for
>> machines sufficiently similar to yours. But it's a lot more delicate to be
>> sure that the eggs actually self-identify correctly, and will be properly
>> ignored on systems where they won't work. This is why IPython has decided
>> against building (official) wheel bdists for at least another release.
>
>
> There has been a lot of discussion about this on the distutils list, and I
> _think_ there is more or less a consensus that we should put binary wheels
> up on PyPi for the python.org builds for Windows and OS-X. Those should work
> at this point (sse issues asside for numpy/scipy)
>
> Doing it for Macports or HomeBrew, or what have you is pretty much alost
> cause, but that's not a big deal -- those are systems designed for people to
> compile there own stuff anyway. similar for Linux.
>
> So what's missing?
>
> And, as you say, zmq is really the only one we need anyway, what exactly is
> iPython not doing?
>
>
>>
>> I am 100% behind a semi-not-so-official-wheels-for-osx effort a la Gohlke,
>> that's actually why I started publishing my own wheels.
>
>
> nice! but not that useful if we don't get the word out.
>
>>
>> But honestly,
>> in a student environment, I would recommend anaconda (or just conda).
>>
> non starter for now -- Again, these are NOT scipy stack classes -- and I do
> want wx, and the guy teaching the next class on web development really wants
> virtualenv.

For wx, if you can figure out how to build a conda recipe for it, that
would help a lot. Basically, you could just host your own recipe on
binstar, and if it works, it's pretty likely that Continuum would pick
it up and ship it with Anaconda. I tried it a while back but I didn't
get very far. But if you're actually familiar with it you might get
further.

As for virtualenv, I really recommend trying conda environments. You
can alias virtualenv="conda create -p" if you want. If you have to
have virtualenv, I was able to get it working inside Anaconda (see
https://github.com/ContinuumIO/conda-recipes/tree/master/virtualenv
and https://binstar.org/asmeurer/virtualenv), but only in Python 2.
Python 3 segfaults for some reason (but in Python 3, you really should
use pyvenv instead of virtualenv).

Aaron Meurer

>
> Anocanda does not work (for now) on those.
>
> Anyway -- I feel very strongly that we should play well with the rest of the
> Python word, and that mean pip and wheels ... and we really can do it now.
>
> I guess I need to do a pull request for the "installing" page of the iPython
> web sire next...
>
> -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
>
> [hidden email]
>
> _______________________________________________
> IPython-dev mailing list
> [hidden email]
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: iPython binary wheels for OS-X

Chris Barker
In reply to this post by Matthias Bussonnier
On Dec 8, 2013, at 10:59 PM, Matthias BUSSONNIER <[hidden email]> wrote:

previous discussion about that:


Thanks for the link. Helpful to understand the issues. It's interesting to me that I've been following the distutils-sig for a good while, and hadn't seen any of this. I suspect one of hold-ups for wheel is the scattered conversation. Though I see Nick on that thread, so that's good.

Chris



I'm sure there are other threads somewhere. 
--
M

Le 9 déc. 2013 à 07:02, Chris Barker a écrit :

On Sun, Dec 8, 2013 at 9:24 PM, MinRK <[hidden email]> wrote:
 
readline should be a dependency on OS X, I know it used to be. The logic may have gotten confused a bit.

Does pip support a way to do platform-dependent dependencies? Anyway, pip isn't lookeing for it for me. Frankly, no biggie, auto-dependencies are nice, but I don't mind hand-installing something if ti's easy to install.

But wouldn't it be a dependency o Windows, too?
 
The warning is still correct, and I still recommend that all OS X users easy_install (not pip) readline. The issue has been discussed in various places (here is one), but it's a sys.path priority issue. Nobody should ever use pip to install readline. But since people still do, incorrectly believing that pip is actually a replacement for easy_install,

well, I'm pretty sure that is the goal -- really we don't want to almost the same package installer for Python....


 
IPython has an unadvertised hack to make the normally never importable pip installed readline available, as long as IPython is the first to try to import it.

hmm -- pretty cool, and it sure works for me, but a bit fragile ;-)
 
pyzmq, the only binary dependency of IPython, has had wheels on OS X and Windows for a few releases now, so `pip install --use-wheel ipython[all]` should already work on a fresh OS X system without any help (after installing pip and wheel, of course).


It sure would be nice if that were advertised a bit.....I really did loo, but of course I never thought just try it!

>
> By the way, the wheels themselves are trivially easy to build, once setup.py build works....

Yes, they are easy to build for yourself, and are typically reusable for machines sufficiently similar to yours. But it's a lot more delicate to be sure that the eggs actually self-identify correctly, and will be properly ignored on systems where they won't work. This is why IPython has decided against building (official) wheel bdists for at least another release.

There has been a lot of discussion about this on the distutils list, and I _think_ there is more or less a consensus that we should put binary wheels up on PyPi for the python.org builds for Windows and OS-X. Those should work at this point (sse issues asside for numpy/scipy)

Doing it for Macports or HomeBrew, or what have you is pretty much alost cause, but that's not a big deal -- those are systems designed for people to compile there own stuff anyway. similar for Linux.

So what's missing?

And, as you say, zmq is really the only one we need anyway, what exactly is iPython not doing?

 
I am 100% behind a semi-not-so-official-wheels-for-osx effort a la Gohlke, that's actually why I started publishing my own wheels.

nice! but not that useful if we don't get the word out.
 
But honestly,
in a student environment, I would recommend anaconda (or just conda).

non starter for now -- Again, these are NOT scipy stack classes -- and I do want wx, and the guy teaching the next class on web development really wants virtualenv.

Anocanda does not work (for now) on those.

Anyway -- I feel very strongly that we should play well with the rest of the Python word, and that mean pip and wheels ... and we really can do it now.

I guess I need to do a pull request for the "installing" page of the iPython web sire next...

-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

[hidden email]
_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev

_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev

_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: iPython binary wheels for OS-X

Chris Barker
In reply to this post by Aaron Meurer
On Dec 9, 2013, at 12:01 AM, Aaron Meurer <[hidden email]> wrote:

What's the reason you can't pip install readline? Is it because pip
insists on compiling it?

No--it needs to be compiled either way--but I _think_ the issue is that pip and easy_install put packages on sys.path differently. The pop way puts it after the existing readline.

If so, wouldn't wheels solve this issue?

Nope-because it's an install-time thing.

But it is a barrier, as it DOES need to be complied. And it DOES need to be installed on the Mac (at least).

-Chris

_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: iPython binary wheels for OS-X

Paul Moore
On 9 December 2013 15:55, Chris Barker - NOAA Federal
<[hidden email]> wrote:
>> What's the reason you can't pip install readline? Is it because pip
>> insists on compiling it?
>
> No--it needs to be compiled either way--but I _think_ the issue is that pip
> and easy_install put packages on sys.path differently. The pop way puts it
> after the existing readline.

easy_install hacks sys.path to put installed packages before the
standard library. That was controversial behaviour at the time it was
implemented, IIRC - Guido specifically did not want to have user
installed packages able to overwrite stdlib behaviour. I don't know if
that position has changed, it's so rarely relevant that I don't think
people care that much (they tend to care more about the nasty pth file
hacks just for their own sake, rather than for the implications :-))

Pip has never implemented path hacks like this, and uses
--single-version-externally-managed which avoids a lot of setuptools'
controversial behaviour.

So, by policy, it's hard to override stdlib modules - even when they
don't work right (which appears to be the issue with readline on OSX,
if I understand the comments in this thread properly). IMO, we'd be a
lot better off readline was split out of the stdlib so that things
like improved OSX support and pyreadline for Windows could be added.
But I doubt that will ever happen :-(

Paul.
_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: iPython binary wheels for OS-X

Chris Barker
On Mon, Dec 9, 2013 at 8:26 AM, Paul Moore <[hidden email]> wrote:
Guido specifically did not want to have user
installed packages able to overwrite stdlib behaviour.

makes some sense...

So, by policy, it's hard to override stdlib modules - even when they
don't work right (which appears to be the issue with readline on OSX,
if I understand the comments in this thread properly). IMO, we'd be a
lot better off readline was split out of the stdlib so that things
like improved OSX support and pyreadline for Windows could be added.
But I doubt that will ever happen :-(

Maybe rather than overriding an stsdlib package, it could be given a new name:

"readline2", or somethign more creative. This wouldn't allow you to install and "fixed" one that would then automagically work everywhere, but would allow 3rd party packages to depend on it. And, of course, it oculd be imported conditionally:

try:
    import readline2 as readline
except:
    import readline

On the other hand, the current third party readline really is a replacement for the (sometimes broken) built-in-readline, so maybe overwriting does make sense in this case -- even though it should be discouraged in teh general case. 

Anyone know if the readline authors would be amenable to putting the path-hack that's in iPyton in readline instead? That's clearly where it belongs...(or is that impossible?, after all it would have to get imported to run, and it wouldn't get imported......) 

-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

[hidden email]

_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: iPython binary wheels for OS-X

Chris Barker
In reply to this post by Aaron Meurer
On Mon, Dec 9, 2013 at 12:01 AM, Aaron Meurer <[hidden email]> wrote:
For wx, if you can figure out how to build a conda recipe for it, that
would help a lot.

Sure. And I think Continuum is working on it now -- so that particular problem may be solved.

But that was just an example -- until/unless we have most arbitrary third party package maintainers building for Anocanda, I"m not going to recommend it to the general user. There are two routes to a solution, though:

1) conda has some key advantages over pip+wheel -- so maybe we should all dump wheel and start using conda -- but this is going to be a hard sell, and Travis, for one, doesn't have the bandwidth to try.

2) make Anaconda / conda / binstar compatible with the python.org pythons and virtualenv.
  - It's actually pretty close now, and I think Continuum is working on closing teh gap, so that may be the way of the future. Not quite the "one way to do it" we'd like, but interoperability is a nice way to get close. What I really don't want is people having to drop their entire python install and use an entirely different one to get one new package -- or even worse there being no one install that supports all the packages a user needs.

But in the meantime, wheels aren't so bad!

(note -- not wheel for wxPython either, and pip-installing it from source is a non-starter. But that's my point. If these various systems are compatible, and one could install a binary intended for the python.org python into an Anocada distribution, users wouldn't find dead ends...

Basically, you could just host your own recipe on
binstar, and if it works, it's pretty likely that Continuum would pick
it up and ship it with Anaconda. I tried it a while back but I didn't
get very far. But if you're actually familiar with it you might get
further.

I might -- but it really is a pain to build, and I haven't done it for years -- and no bandwidth at the moment. Maybe at some point.

As for virtualenv, I really recommend trying conda environments.

Well, this is about standards, not technology -- maybe conda environments are better, but the web-dev folks are all pretty committed to pip and virtualenv.

-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

[hidden email]

_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: iPython binary wheels for OS-X

MinRK
In reply to this post by Chris Barker



On Mon, Dec 9, 2013 at 8:40 AM, Chris Barker <[hidden email]> wrote:
On Mon, Dec 9, 2013 at 8:26 AM, Paul Moore <[hidden email]> wrote:
Guido specifically did not want to have user
installed packages able to overwrite stdlib behaviour.

makes some sense...

So, by policy, it's hard to override stdlib modules - even when they
don't work right (which appears to be the issue with readline on OSX,
if I understand the comments in this thread properly). IMO, we'd be a
lot better off readline was split out of the stdlib so that things
like improved OSX support and pyreadline for Windows could be added.
But I doubt that will ever happen :-(

Maybe rather than overriding an stsdlib package, it could be given a new name:

"readline2", or somethign more creative. This wouldn't allow you to install and "fixed" one that would then automagically work everywhere, but would allow 3rd party packages to depend on it. And, of course, it oculd be imported conditionally:

try:
    import readline2 as readline
except:
    import readline

I actually made just this PR yesterday, it would solve the issue for IPython, if not in general.
 

On the other hand, the current third party readline really is a replacement for the (sometimes broken) built-in-readline, so maybe overwriting does make sense in this case -- even though it should be discouraged in teh general case. 

Anyone know if the readline authors would be amenable to putting the path-hack that's in iPyton in readline instead? That's clearly where it belongs...(or is that impossible?, after all it would have to get imported to run, and it wouldn't get imported......) 

The path hack must be in the importer of readline, not readline itself.
 

-Chris


--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            <a href="tel:%28206%29%20526-6959" value="+12065266959" target="_blank">(206) 526-6959   voice
7600 Sand Point Way NE   <a href="tel:%28206%29%20526-6329" value="+12065266329" target="_blank">(206) 526-6329   fax
Seattle, WA  98115       <a href="tel:%28206%29%20526-6317" value="+12065266317" target="_blank">(206) 526-6317   main reception

[hidden email]

_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev



_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: iPython binary wheels for OS-X

Chris Barker
On Mon, Dec 9, 2013 at 9:41 AM, MinRK <[hidden email]> wrote:
I actually made just this PR yesterday, it would solve the issue for IPython, if not in general.


thanks -- good idea.

Anyone know if the readline authors would be amenable to putting the path-hack that's in iPyton in readline instead? That's clearly where it belongs...(or is that impossible?, after all it would have to get imported to run, and it wouldn't get imported......) 

The path hack must be in the importer of readline, not readline itself.
 

I was hoping that someone smarter than me could figure out how to monkey-patch it on the fly -- but it probably really is impossible.

Tiny note on the PR: it's not just that people _are_ installing readline with pip -- it's that it's that they _should_ be able to expect that to work.


-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

[hidden email]

_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: iPython binary wheels for OS-X

Aaron Meurer
In reply to this post by Paul Moore
On Mon, Dec 9, 2013 at 9:26 AM, Paul Moore <[hidden email]> wrote:

> On 9 December 2013 15:55, Chris Barker - NOAA Federal
> <[hidden email]> wrote:
>>> What's the reason you can't pip install readline? Is it because pip
>>> insists on compiling it?
>>
>> No--it needs to be compiled either way--but I _think_ the issue is that pip
>> and easy_install put packages on sys.path differently. The pop way puts it
>> after the existing readline.
>
> easy_install hacks sys.path to put installed packages before the
> standard library. That was controversial behaviour at the time it was
> implemented, IIRC - Guido specifically did not want to have user
> installed packages able to overwrite stdlib behaviour. I don't know if
> that position has changed, it's so rarely relevant that I don't think
> people care that much (they tend to care more about the nasty pth file
> hacks just for their own sake, rather than for the implications :-))

Does Python 3.3 help the situation? They refactored the import system
quite a bit there.

Aaron Meurer

>
> Pip has never implemented path hacks like this, and uses
> --single-version-externally-managed which avoids a lot of setuptools'
> controversial behaviour.
>
> So, by policy, it's hard to override stdlib modules - even when they
> don't work right (which appears to be the issue with readline on OSX,
> if I understand the comments in this thread properly). IMO, we'd be a
> lot better off readline was split out of the stdlib so that things
> like improved OSX support and pyreadline for Windows could be added.
> But I doubt that will ever happen :-(
>
> Paul.
> _______________________________________________
> IPython-dev mailing list
> [hidden email]
> http://mail.scipy.org/mailman/listinfo/ipython-dev
_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: iPython binary wheels for OS-X

Aaron Meurer
In reply to this post by Chris Barker
There's the rl library. https://pypi.python.org/pypi/rl.

Aaron Meurer

On Mon, Dec 9, 2013 at 9:40 AM, Chris Barker <[hidden email]> wrote:

> On Mon, Dec 9, 2013 at 8:26 AM, Paul Moore <[hidden email]> wrote:
>>
>> Guido specifically did not want to have user
>> installed packages able to overwrite stdlib behaviour.
>
>
> makes some sense...
>
>> So, by policy, it's hard to override stdlib modules - even when they
>> don't work right (which appears to be the issue with readline on OSX,
>> if I understand the comments in this thread properly). IMO, we'd be a
>> lot better off readline was split out of the stdlib so that things
>> like improved OSX support and pyreadline for Windows could be added.
>> But I doubt that will ever happen :-(
>
>
> Maybe rather than overriding an stsdlib package, it could be given a new
> name:
>
> "readline2", or somethign more creative. This wouldn't allow you to install
> and "fixed" one that would then automagically work everywhere, but would
> allow 3rd party packages to depend on it. And, of course, it oculd be
> imported conditionally:
>
> try:
>     import readline2 as readline
> except:
>     import readline
>
> On the other hand, the current third party readline really is a replacement
> for the (sometimes broken) built-in-readline, so maybe overwriting does make
> sense in this case -- even though it should be discouraged in teh general
> case.
>
> Anyone know if the readline authors would be amenable to putting the
> path-hack that's in iPyton in readline instead? That's clearly where it
> belongs...(or is that impossible?, after all it would have to get imported
> to run, and it wouldn't get imported......)
>
> -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
>
> [hidden email]
>
> _______________________________________________
> IPython-dev mailing list
> [hidden email]
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: iPython binary wheels for OS-X

Chris Barker
On Mon, Dec 9, 2013 at 2:42 PM, Aaron Meurer <[hidden email]> wrote:
There's the rl library. https://pypi.python.org/pypi/rl.

Any idea if it supports (a superset of) the same API as the built-in readline?

-Chris





 
Aaron Meurer

On Mon, Dec 9, 2013 at 9:40 AM, Chris Barker <[hidden email]> wrote:
> On Mon, Dec 9, 2013 at 8:26 AM, Paul Moore <[hidden email]> wrote:
>>
>> Guido specifically did not want to have user
>> installed packages able to overwrite stdlib behaviour.
>
>
> makes some sense...
>
>> So, by policy, it's hard to override stdlib modules - even when they
>> don't work right (which appears to be the issue with readline on OSX,
>> if I understand the comments in this thread properly). IMO, we'd be a
>> lot better off readline was split out of the stdlib so that things
>> like improved OSX support and pyreadline for Windows could be added.
>> But I doubt that will ever happen :-(
>
>
> Maybe rather than overriding an stsdlib package, it could be given a new
> name:
>
> "readline2", or somethign more creative. This wouldn't allow you to install
> and "fixed" one that would then automagically work everywhere, but would
> allow 3rd party packages to depend on it. And, of course, it oculd be
> imported conditionally:
>
> try:
>     import readline2 as readline
> except:
>     import readline
>
> On the other hand, the current third party readline really is a replacement
> for the (sometimes broken) built-in-readline, so maybe overwriting does make
> sense in this case -- even though it should be discouraged in teh general
> case.
>
> Anyone know if the readline authors would be amenable to putting the
> path-hack that's in iPyton in readline instead? That's clearly where it
> belongs...(or is that impossible?, after all it would have to get imported
> to run, and it wouldn't get imported......)
>
> -Chris
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R            <a href="tel:%28206%29%20526-6959" value="+12065266959">(206) 526-6959   voice
> 7600 Sand Point Way NE   <a href="tel:%28206%29%20526-6329" value="+12065266329">(206) 526-6329   fax
> Seattle, WA  98115       <a href="tel:%28206%29%20526-6317" value="+12065266317">(206) 526-6317   main reception
>
> [hidden email]
>
> _______________________________________________
> IPython-dev mailing list
> [hidden email]
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev



--

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

[hidden email]

_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: iPython binary wheels for OS-X

Aaron Meurer
In reply to this post by Chris Barker
On Mon, Dec 9, 2013 at 10:30 AM, Chris Barker <[hidden email]> wrote:

> On Mon, Dec 9, 2013 at 12:01 AM, Aaron Meurer <[hidden email]> wrote:
>>
>> For wx, if you can figure out how to build a conda recipe for it, that
>> would help a lot.
>
>
> Sure. And I think Continuum is working on it now -- so that particular
> problem may be solved.
>
> But that was just an example -- until/unless we have most arbitrary third
> party package maintainers building for Anocanda, I"m not going to recommend
> it to the general user. There are two routes to a solution, though:
>
> 1) conda has some key advantages over pip+wheel -- so maybe we should all
> dump wheel and start using conda -- but this is going to be a hard sell, and
> Travis, for one, doesn't have the bandwidth to try.

Also read http://technicaldiscovery.blogspot.com/2013/12/why-i-promote-conda.html.
To quote: "several of us asked Guido what we can do to fix Python
packaging for the NumPy stack.   Guido's answer was to 'solve the
problem ourselves'. "

>
> 2) make Anaconda / conda / binstar compatible with the python.org pythons
> and virtualenv.
>   - It's actually pretty close now, and I think Continuum is working on
> closing teh gap, so that may be the way of the future. Not quite the "one
> way to do it" we'd like, but interoperability is a nice way to get close.
> What I really don't want is people having to drop their entire python
> install and use an entirely different one to get one new package -- or even
> worse there being no one install that supports all the packages a user
> needs.
>
> But in the meantime, wheels aren't so bad!
>
> (note -- not wheel for wxPython either, and pip-installing it from source is
> a non-starter. But that's my point. If these various systems are compatible,
> and one could install a binary intended for the python.org python into an
> Anocada distribution, users wouldn't find dead ends...
>
>> Basically, you could just host your own recipe on
>> binstar, and if it works, it's pretty likely that Continuum would pick
>> it up and ship it with Anaconda. I tried it a while back but I didn't
>> get very far. But if you're actually familiar with it you might get
>> further.
>
>
> I might -- but it really is a pain to build, and I haven't done it for years
> -- and no bandwidth at the moment. Maybe at some point.
>
>> As for virtualenv, I really recommend trying conda environments.
>
>
> Well, this is about standards, not technology -- maybe conda environments
> are better, but the web-dev folks are all pretty committed to pip and
> virtualenv.

I figured as much. But as I noted, in Python 2 at least, in my minimal
testing, virtualenv actually seems to work just fine, once you have a
conda recipe for it. I've built a handful of conda recipes that have
virtualenv as a hard dependency and they all seemed to work as well.

Aaron Meurer

>
> -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
>
> [hidden email]
>
> _______________________________________________
> IPython-dev mailing list
> [hidden email]
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: iPython binary wheels for OS-X

Aaron Meurer
In reply to this post by Chris Barker
On Mon, Dec 9, 2013 at 3:44 PM, Chris Barker <[hidden email]> wrote:
> On Mon, Dec 9, 2013 at 2:42 PM, Aaron Meurer <[hidden email]> wrote:
>>
>> There's the rl library. https://pypi.python.org/pypi/rl.
>>
> Any idea if it supports (a superset of) the same API as the built-in
> readline?
>
> -Chris

I'm not 100%, but I think it does. It definitely supports way more
things than built-in readline. But I'm not 100% sure if everything
from readline is also in rl. Anyway, if it doesn't, it's all open
source :)

Aaron Meurer

>
>
>
>
>
>
>>
>> Aaron Meurer
>>
>> On Mon, Dec 9, 2013 at 9:40 AM, Chris Barker <[hidden email]>
>> wrote:
>> > On Mon, Dec 9, 2013 at 8:26 AM, Paul Moore <[hidden email]> wrote:
>> >>
>> >> Guido specifically did not want to have user
>> >> installed packages able to overwrite stdlib behaviour.
>> >
>> >
>> > makes some sense...
>> >
>> >> So, by policy, it's hard to override stdlib modules - even when they
>> >> don't work right (which appears to be the issue with readline on OSX,
>> >> if I understand the comments in this thread properly). IMO, we'd be a
>> >> lot better off readline was split out of the stdlib so that things
>> >> like improved OSX support and pyreadline for Windows could be added.
>> >> But I doubt that will ever happen :-(
>> >
>> >
>> > Maybe rather than overriding an stsdlib package, it could be given a new
>> > name:
>> >
>> > "readline2", or somethign more creative. This wouldn't allow you to
>> > install
>> > and "fixed" one that would then automagically work everywhere, but would
>> > allow 3rd party packages to depend on it. And, of course, it oculd be
>> > imported conditionally:
>> >
>> > try:
>> >     import readline2 as readline
>> > except:
>> >     import readline
>> >
>> > On the other hand, the current third party readline really is a
>> > replacement
>> > for the (sometimes broken) built-in-readline, so maybe overwriting does
>> > make
>> > sense in this case -- even though it should be discouraged in teh
>> > general
>> > case.
>> >
>> > Anyone know if the readline authors would be amenable to putting the
>> > path-hack that's in iPyton in readline instead? That's clearly where it
>> > belongs...(or is that impossible?, after all it would have to get
>> > imported
>> > to run, and it wouldn't get imported......)
>> >
>> > -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
>> >
>> > [hidden email]
>> >
>> > _______________________________________________
>> > IPython-dev mailing list
>> > [hidden email]
>> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>> >
>> _______________________________________________
>> IPython-dev mailing list
>> [hidden email]
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
>
>
> --
>
> 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
>
> [hidden email]
>
> _______________________________________________
> IPython-dev mailing list
> [hidden email]
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: iPython binary wheels for OS-X

MinRK



On Mon, Dec 9, 2013 at 2:47 PM, Aaron Meurer <[hidden email]> wrote:
On Mon, Dec 9, 2013 at 3:44 PM, Chris Barker <[hidden email]> wrote:
> On Mon, Dec 9, 2013 at 2:42 PM, Aaron Meurer <[hidden email]> wrote:
>>
>> There's the rl library. https://pypi.python.org/pypi/rl.
>>
> Any idea if it supports (a superset of) the same API as the built-in
> readline?
>
> -Chris

I'm not 100%, but I think it does. It definitely supports way more
things than built-in readline. But I'm not 100% sure if everything
from readline is also in rl. Anyway, if it doesn't, it's all open
source :)

Looks like it's pretty much compatible. This might the the way to go, though Ludwig just merged my PR on python-readline, which we know already works.

One of the sticky things with wheels (and easy with setup.py) is that a readline package should only be a dependency if stdlib readline is actually libedit. That's true of System Python and Python.org, but it is not true of conda Python or macports (both of which regularly pip install ipython, so it matters, even though they both have IPython packages). So if IPython is going to start building wheels, it needs to be able to express dependencies like that, and the platform is simply insufficient information.

-MinRK
 

Aaron Meurer

>
>
>
>
>
>
>>
>> Aaron Meurer
>>
>> On Mon, Dec 9, 2013 at 9:40 AM, Chris Barker <[hidden email]>
>> wrote:
>> > On Mon, Dec 9, 2013 at 8:26 AM, Paul Moore <[hidden email]> wrote:
>> >>
>> >> Guido specifically did not want to have user
>> >> installed packages able to overwrite stdlib behaviour.
>> >
>> >
>> > makes some sense...
>> >
>> >> So, by policy, it's hard to override stdlib modules - even when they
>> >> don't work right (which appears to be the issue with readline on OSX,
>> >> if I understand the comments in this thread properly). IMO, we'd be a
>> >> lot better off readline was split out of the stdlib so that things
>> >> like improved OSX support and pyreadline for Windows could be added.
>> >> But I doubt that will ever happen :-(
>> >
>> >
>> > Maybe rather than overriding an stsdlib package, it could be given a new
>> > name:
>> >
>> > "readline2", or somethign more creative. This wouldn't allow you to
>> > install
>> > and "fixed" one that would then automagically work everywhere, but would
>> > allow 3rd party packages to depend on it. And, of course, it oculd be
>> > imported conditionally:
>> >
>> > try:
>> >     import readline2 as readline
>> > except:
>> >     import readline
>> >
>> > On the other hand, the current third party readline really is a
>> > replacement
>> > for the (sometimes broken) built-in-readline, so maybe overwriting does
>> > make
>> > sense in this case -- even though it should be discouraged in teh
>> > general
>> > case.
>> >
>> > Anyone know if the readline authors would be amenable to putting the
>> > path-hack that's in iPyton in readline instead? That's clearly where it
>> > belongs...(or is that impossible?, after all it would have to get
>> > imported
>> > to run, and it wouldn't get imported......)
>> >
>> > -Chris
>> >
>> >
>> > --
>> >
>> > Christopher Barker, Ph.D.
>> > Oceanographer
>> >
>> > Emergency Response Division
>> > NOAA/NOS/OR&R            <a href="tel:%28206%29%20526-6959" value="+12065266959">(206) 526-6959   voice
>> > 7600 Sand Point Way NE   <a href="tel:%28206%29%20526-6329" value="+12065266329">(206) 526-6329   fax
>> > Seattle, WA  98115       <a href="tel:%28206%29%20526-6317" value="+12065266317">(206) 526-6317   main reception
>> >
>> > [hidden email]
>> >
>> > _______________________________________________
>> > IPython-dev mailing list
>> > [hidden email]
>> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>> >
>> _______________________________________________
>> IPython-dev mailing list
>> [hidden email]
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R            <a href="tel:%28206%29%20526-6959" value="+12065266959">(206) 526-6959   voice
> 7600 Sand Point Way NE   <a href="tel:%28206%29%20526-6329" value="+12065266329">(206) 526-6329   fax
> Seattle, WA  98115       <a href="tel:%28206%29%20526-6317" value="+12065266317">(206) 526-6317   main reception
>
> [hidden email]
>
> _______________________________________________
> IPython-dev mailing list
> [hidden email]
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev


_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: iPython binary wheels for OS-X

Paul Moore
In reply to this post by Aaron Meurer
On 9 December 2013 22:40, Aaron Meurer <[hidden email]> wrote:

>> easy_install hacks sys.path to put installed packages before the
>> standard library. That was controversial behaviour at the time it was
>> implemented, IIRC - Guido specifically did not want to have user
>> installed packages able to overwrite stdlib behaviour. I don't know if
>> that position has changed, it's so rarely relevant that I don't think
>> people care that much (they tend to care more about the nasty pth file
>> hacks just for their own sake, rather than for the implications :-))
>
> Does Python 3.3 help the situation? They refactored the import system
> quite a bit there.

Not particularly - ultimately, the key point here is that you're not
*supposed* to override the standard library modules (as I understand
it - this is only my recollection of the debates at the time!)

To me, the real fix would be for IPython to import its *own* readline,
which wraps the stdlib readline when appropriate, and other modules as
needed. Then there's no overriding and no name clashes to worry about.
(If that was done, pyreadline could also stop making itself available
as "readline" so it too becomes available only when requested). AIUI,
that's what MinRK's patch does.

Ideally, the core Python interactive prompt would *also* allow users
to plug in their own readline functionality, but that's somewhat
orthogonal to how external projects like IPython deal with the issue.
Paul
_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
Reply | Threaded
Open this post in threaded view
|

Re: iPython binary wheels for OS-X

MinRK



On Mon, Dec 9, 2013 at 3:28 PM, Paul Moore <[hidden email]> wrote:
On 9 December 2013 22:40, Aaron Meurer <[hidden email]> wrote:
>> easy_install hacks sys.path to put installed packages before the
>> standard library. That was controversial behaviour at the time it was
>> implemented, IIRC - Guido specifically did not want to have user
>> installed packages able to overwrite stdlib behaviour. I don't know if
>> that position has changed, it's so rarely relevant that I don't think
>> people care that much (they tend to care more about the nasty pth file
>> hacks just for their own sake, rather than for the implications :-))
>
> Does Python 3.3 help the situation? They refactored the import system
> quite a bit there.

Not particularly - ultimately, the key point here is that you're not
*supposed* to override the standard library modules (as I understand
it - this is only my recollection of the debates at the time!)

To me, the real fix would be for IPython to import its *own* readline,
which wraps the stdlib readline when appropriate, and other modules as
needed. Then there's no overriding and no name clashes to worry about.
(If that was done, pyreadline could also stop making itself available
as "readline" so it too becomes available only when requested). AIUI,
that's what MinRK's patch does.

This is what IPython already does (in utils.rlineimpl). The only missing piece was that the readline package used the name 'readline'. I should have proposed giving it a non-colliding name as soon as we started seeing the problems caused by pip. I don't know why I didn't do it sooner, it totally solves the issue.
 

Ideally, the core Python interactive prompt would *also* allow users
to plug in their own readline functionality, but that's somewhat
orthogonal to how external projects like IPython deal with the issue.

an import statement in PYTHONSTARTUP might be sufficient.
 
Paul
_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev


_______________________________________________
IPython-dev mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-dev
12