Is adding new Fortran to SciPy generally allowed?

[nbelakovski]

OK, so I guess to summarize, the conclusion is that in general no new Fortran is allowed except for modern Fortran implementations of algorithms that are already in scipy, and as far as optional dependencies go, are we making an exception for that in the case of PRIMA or are we saying that if someone else comes along with a new algorithm in Fortran, that it can be accepted if it can be made as an optional dependency?

Either way, @rgommers I think we’re waiting for your review on the PR to integrate PRIMA to replace COBYLA (just saw your comments, not sure how I missed them earlier): ENH: optimize: integrate the PRIMA library for COBYLA by nbelakovski · Pull Request #20964 · scipy/scipy · GitHub. It looks like there’s a new test for Linux aarch64 which is failing so I’ll take a look at that (it looks like a recursive submodule issue with one of the submodules in PRIMA), but otherwise I think it’s ready for review, and of course the implementation of the optional dependencies can happen in a separate PR.

And as far as going Fortran free goes, it sounds like the aim is to go Fortran free, but if the compiler support situation improves before that goal is reached, then SciPy will reevaluate? That doesn’t sound like a great motivator for people like @ilayn who are working on that, but I’m just trying to summarize here, not propose a policy (don’t shoot the messenger!)

[rgommers]

@nbelakovski

OK, so I guess to summarize, the conclusion is that in general no new Fortran is allowed except for modern Fortran implementations of algorithms that are already in scipy,

That sounds right, yes.

@nbelakovski

and as far as optional dependencies go, are we making an exception for that in the case of PRIMA or are we saying that if someone else comes along with a new algorithm in Fortran, that it can be accepted if it can be made as an optional dependency?

I’d be a bit more specific: we’d accept an optional dependency here because the functionality is very closely related to what we already have in SciPy and can be used via a SciPy function (minimize). If it’s only new functionality and there’s no API interaction like with minimize, I’d say simply a separate package (so a plain “no” from us) is the default answer. An optional dependency also has a cost, so it needs a good reason.

@nbelakovski

And as far as going Fortran free goes, it sounds like the aim is to go Fortran free, but if the compiler support situation improves before that goal is reached, then SciPy will reevaluate?

Yes in principle, but also let me note that (a) progress is currently fast so we may well be Fortran-free within a year, and (b) the “re-evaluate” is something we can/will do for any topic if circumstances change - the benefits of Fortran removal are still very large, so it’s hard to imagine the verdict changing unless the removal effort runs into a blocker or stalls for some reason.