[PATCH] math/py-numpy: add FORTRAN and NOBLAS options

[kiwi]

Summary

math/py-numpy: add FORTRAN and NOBLAS options

This allow to run numpy withou any fortran/gcc dependencies.
In some case this can be needed in some specifics environment
to not have such dependencies.
No defaults options has been switched.

PR:     268348
Approved by:    0mp (mentor)
Sponsored by:   Klara, Inc.
Sponsored by:   OPNsense

Test Plan

Tested build with defaults options and with NOBLAS and FORTRAN unseted on poudriere.

[vishwin]

Please elaborate further on "in some case this can be needed in some specifics environment to not have such dependencies." numpy isn't exactly meant to run on constricted environments, and fortran and BLAS support are generally considered fundamental components. Adding these options invites noise from those shooting themselves in the foot.

As for the proposed changes themselves, these will not apply after numpy is switched to building under PEP-517, amongst other things.

[kevans]

In D52146#1191059, @vishwin wrote:

Please elaborate further on "in some case this can be needed in some specifics environment to not have such dependencies." numpy isn't exactly meant to run on constricted environments, and fortran and BLAS support are generally considered fundamental components. Adding these options invites noise from those shooting themselves in the foot.

e.g., routers, which likely don't want to drop some valuable storage on GCC. You'll note in the PR that they're just running py-duckdb, which has numpy as a dependency but doesn't really need BLAS.

If you're toggling non-default options on a port like numpy, you really need to understand the consequences of it.

As for the proposed changes themselves, these will not apply after numpy is switched to building under PEP-517, amongst other things.

Can you suggest a better approach that would be compatible going forawrd? (When is the PEP-517 switch actually going to happen?)

It's unfortunate that we couldn't have gotten python@ feedback of this sort on this at any point in the last three years that the PR has been open- I guess we need more python@ staffing. =\

[vishwin]

In D52146#1191167, @kevans wrote:

e.g., routers, which likely don't want to drop some valuable storage on GCC. You'll note in the PR that they're just running py-duckdb, which has numpy as a dependency but doesn't really need BLAS.

This is not numpy's problem. I also commented in the PR but it bears repeating, anything built with GCC, including with gfortran in this case, needs the GCC libraries to operate properly. flang exists but I haven't had a chance to try building with it yet, but is part of the larger overhaul.

If you're toggling non-default options on a port like numpy, you really need to understand the consequences of it.

In the Python world, we cannot underestimate pilot errors. You need to consider the userbase of numpy, many of whom are not necessarily as versed in software like we are, and just see "ooh reduce dependency". Disabling fortran support is a pretty fatal one.

As for the proposed changes themselves, these will not apply after numpy is switched to building under PEP-517, amongst other things.

Can you suggest a better approach that would be compatible going forawrd? (When is the PEP-517 switch actually going to happen?)

It's been in my tree for quite some time, but simply missing some sanity checks.

It's unfortunate that we couldn't have gotten python@ feedback of this sort on this at any point in the last three years that the PR has been open- I guess we need more python@ staffing. =\

It's also unfortunate that the Python ecosystem overall has a very particular way of doing things and is a mess to even start learning.