ebuilds dependancies should be updated to what is now replacing Numarray and Numeric: NumPy As of the home of "Numerical Python" (http://numeric.scipy.org/): It derives from the old Numeric code base and can be used as a replacement for Numeric. It also adds the features introduced by numarray and can be used to replace numarray. Numeric users should find the transition very easy. I may understand the work to be big. So I could suggest creating a virtual package for numerical python. Then one could choose wich one to use to provides fonctinalities. Right now, some ebuils depends explicitly on Numeric/Numarray and that blocks me from using them. Thanx
I've found the problematic ebuild for me : dev-python/pygtk In the rdepend section, !arm? ( dev-python/numeric ) should be replaced with: !arm? ( || ( dev-python/numeric dev-python/numpy ) ) This would prevent the use of virtual...
(In reply to comment #0) > ebuilds dependancies should be updated to what is now replacing Numarray and > Numeric: NumPy Although i agree that this replacement should eventually happen when NumPy is mature enough, i do not think it would be a good idea at this point. NumPy is still under active develpment, and various projects that were using numarray (and possibly Numeric as well) are still explicitly requiring numarray or Numeric, holding off NumPy adoption until a stable version is available and compatibility issues addressed. Considering that NumPy can coexist in python's site-packages with Numeric and numarray without any problems, i propose to do just that: let all three of them coexist until all dust settles. As far as dependencies go, i'd propose to let them default to what packages' authors required (e.g., dev-python/numeric for dev-python/pygtk in your case above), but also add dev-python/numpy as a possibility if Numeric or numarray is not available (again, in the way you specified above). This way, the choice will be up to the user. However, it would still be a good idea to *test* that NumPy works OK with the package before allowing it as a dependency... I am also wondering how you solved the problem of having e.g. pygtk import NumPy when the actual pygtk code imports Numeric.
I would definitely keep the old around. There is never a shortage of scientific software that makes use of antiquated libraries. And they don't conflict with each other so it's easy keeping both numeric and numpy around.
numeric and numarray are still widely used. numpy intends to replace them both, but not so many packages made the migration. I would keep them three in portage.
I'm closing this as wontfix because there are still many packages that work with numeric/numarray. Unless there is a security concern or a maintenance problem, I don't think we really need to retire Numeric/numarray just to reduce two packages from portage.
