On Wed, Mar 6, 2013 at 9:30 AM, francis picabia
<fpicabia@gmail.com> wrote:
A developer wanted packages python-networkx python-numpy python-scipy python-matplotlib
amongst others. Then I learned he had developed everything in Ubuntu where 2.7 is
the standard version.
No problem, add a repo for testing and install python2.7
There are two problems with the shopping list within testing.
python2.7-matplotlib is not among the 500+ python*
packages in testing.
If I do:
aptitude -t testing install python2.7-scipy python2.7-numpy
It comes back with a suggestion to remove 44 packages from the system
including gcc, virt-manager, etc.
Is there a way to add in these 2.7 packages without interfering with
core python 2.6 (as installing python2.7 was able to be a simple alternate)?
I've seen something called pip but never used it. Is this like pear/pecl for php?
Would that be the key? How to control it so it doesn't clobber python 2.6 land?
My solution was to install a python from source under /usr/local
Then pip was installed from source in same area. It was crucial
to have that python in my path first as "python2.7". Then pip could
be used to install (compile from source) python packages.
pip is more like cpan for perl, than pear/pecl for php, except
unlike cpan, you'll be getting the dependancies manually.
In my case, the packages were for math plotting, so the sources
include C and fortran. Given that C libraries are involved, this
explains why those packages haul in a lot of dependencies
if you try to install same from testing.
The other option would have been to upgrade to a wheezy RC,
but this could entail a risk I don't want given it is a multi-user
multi-purpose system and there are still unresolved bugs related
to dist-upgrade.