This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

Just a little history from a maintainer of the numpy packager for EPEL4 and EPEL5 prior to its transition into a supported RHEL 6 software package,

When numpy was transitioned into RHEL 6 away from EPEL, and I was informed of that. I made the suggestion that RH engineering also take matplotlib and scipy into RHEL in order to keep these things together as they are very closely related
upstream. I do not know the specific reason why numpy made the jump as I am not privy to RHEL engineering decisions as to which software they decide to support.

I'm also not a customer of RHEL as a product so I don't have any skin in the
game with regard to setting RHEL engineering policies. And I appreciate the
fact that they need to make hard decisions as to what that means in the package
landscape and I accept the fact shifts in the packaging support in RHEL
necessarily impact what EPEL can deliver. I know the score and I am not mad or offended in any way for the decision.

That being said, from my perspective, I believe that pulling in numpy without
pulling in matplotlib and scipy was a mistake that hurts scientific users who rely on this software.  Mistakes happen, I hold no grudges in that regard.  If there are paying RHEL support customers who come across this ticket who rely on matplotlib and/or scipy, I would highly encourage you to make your Red Hat support representative aware that you would like them to keep numpy/matplotlib/scipy synced and supported as a group of packages because they form a coherent
framework for scientific analysis which numpy by itself does not provide for.



-jef

As a paying RHEL customer whose users do rely on the numpy/scipy/matplotlib software set, I will contact my support representative - I agree with Jef that "bringing in" numpy to RHEL6 w/o scipy and matplotlib was a mistake.

(In reply to comment #4)
> As a paying RHEL customer whose users do rely on the numpy/scipy/matplotlib
> software set, I will contact my support representative - I agree with Jef that
> "bringing in" numpy to RHEL6 w/o scipy and matplotlib was a mistake.

I forgot to add - my bugzilla account is linked to my personal email, but my paying RHEL status is with my employer - UT-Austin Astronomy.

re comment 3: yes I agree that at least SciPy should be maintained together with NumPy, because they even have one upstream. NumPy 1.4 has been around for a while in Fedora 14 without major issues. As far as compatibility goes, 1.4.x should by all means be backward-compatible apart from 2 small items. Upstream keeps good release notes on the matter. See https://github.com/numpy/numpy/blob/v1.4.1/doc/release/1.4.0-notes.rst for changes from 1.3.0.

(In reply to comment #4)
> As a paying RHEL customer whose users do rely on the numpy/scipy/matplotlib
> software set, I will contact my support representative - I agree with Jef that
> "bringing in" numpy to RHEL6 w/o scipy and matplotlib was a mistake.

I've filed bug 697530 to add SciPy to distribution, feel free to file another one for matplotlib and let your support representative know.

Most notable part of release notes are deprecations. Copy-pasting here:
> Deprecations
> 
> The following functions are deprecated:
> 
>         correlate: it takes a new keyword argument old_behavior. When True (the default), it returns the same result as before. When False, compute the conventional correlation, and take the conjugate for complex arrays. The old behavior will be removed in NumPy 1.5, and raises a DeprecationWarning in 1.4.
>         unique1d: use unique instead. unique1d raises a deprecation warning in 1.4, and will be removed in 1.5.
>         intersect1d_nu: use intersect1d instead. intersect1d_nu raises a deprecation warning in 1.4, and will be removed in 1.5.
>         setmember1d: use in1d instead. setmember1d raises a deprecation warning in 1.4, and will be removed in 1.5.
> 
> The following raise errors:
> 
>         When operating on 0-d arrays, numpy.max and other functions accept only axis=0, axis=-1 and axis=None. Using an out-of-bounds axes is an indication of a bug, so Numpy raises an error for these cases now.
>         Specifying axis > MAX_DIMS is no longer allowed; Numpy raises now an error instead of behaving similarly as for axis=None.

Only last two changes could potentially cause problems with backward compatibility, but those would be really limited to few use cases and would be minor.

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
This version of NumPy changes behaviour from previous version in two cases:

 1. When operating on 0-d arrays, numpy.max and other functions accept only axis=0, axis=-1 and axis=None. Using an out-of-bounds axes is an indication of a bug, so Numpy raises an error for these cases now.
 2. Specifying axis > MAX_DIMS is no longer allowed; Numpy raises now an error instead of behaving similarly as for axis=None.

   2. What is the nature and description of the request?

update numpy to at least 1.4.1 version in rhel 6 or provide SciPy and
matplotlib along with the recently added numpy as the trio are closely tied
together. 

   3. Why does the customer need this? (List the business requirements here)

At the customer, RHEL environments are used by many researchers who are
working on both internally and externally funded research projects. A
significant number of these researches unconditionally require the
analytical tools provided by the trio that is Numpy + SciPy + matplotlib.

    4. How would the customer like to achieve this? (List the functional
requirements here)

The numpy package version 1.4.1 version or later should be available in rhel
6 or add SciPy + matplotlib packages to the rhel 6 channel

    5. For each functional requirement listed in question 4, specify how Red
Hat and the customer can test to confirm the requirement is successfully
implemented.

The customer should be able to get numpy package version 1.4.1 version or
later or SciPy + matplotlib packages in the rhel6 channel.

    6. Is there already an existing RFE upstream or in Red Hat bugzilla?

Yes, https://bugzilla.redhat.com/show_bug.cgi?id=692959

    7. How quickly does this need resolved? (desired target release)
 
Minor release

   8. Does this request meet the RHEL Bug and Feature Inclusion Criteria
(please review)

Yes

   9. List the affected packages

numpy

   10. Would the customer be able to assist in testing this functionality if
implemented?

Yes

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,4 +1,5 @@
-This version of NumPy changes behaviour from previous version in two cases:
+Updated NumPy package
+The NumPy package which is designed to manipulate large multi-dimensional arrays of arbitrary records has been updated to version 1.4.1. This updated version includes these changes:
 
- 1. When operating on 0-d arrays, numpy.max and other functions accept only axis=0, axis=-1 and axis=None. Using an out-of-bounds axes is an indication of a bug, so Numpy raises an error for these cases now.
+    When operating on 0-d arrays, numpy.max and other functions accept only the following parameters: axis=0, axis=-1, and axis=None. Using out-of-bounds axes indicates a bug, for which NumPy now raises an error.
- 2. Specifying axis > MAX_DIMS is no longer allowed; Numpy raises now an error instead of behaving similarly as for axis=None.+    Specifying the axis > MAX_DIMS parameter is no longer allowed; NumPy now raises an error, instead of behaving the same as when axis=None was specified.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0986.html