On 10/25/20 11:39 AM, Dustin Spicuzza wrote: > On 10/25/20 5:23 AM, Matti Picus wrote: >> On 10/25/20 10:46 AM, Dustin Spicuzza wrote: >>> I took a first stab at it, and... surprise, surprise, there were a few >>> more warts than I had originally expected in my initial survey. The >>> biggest unexpected result is that numpy.f2py would need to also be a >>> toplevel package. I did get the refactor cross-compiled and started on >>> scipy, but there's a few more issues that will have to be resolved on >>> the scipy side. >>> >>> I posted a detailed set of notes on the issue (#17620) and made a draft >>> PR with my initial results (#17632) if you want to get a sense for how >>> invasive this is (or isn't depending on your point of view). >>> >>> Dustin >>> >> Is there a way to do this without modifying SciPy? That would reassure >> me that this change will not break other peoples' workflow. It is hard >> to believe that only SciPy uses numpy.distutils. If the changes break >> backward compatibility, they need to be done like any other >> deprecation: warn for 4 releases (two years) before actually breaking >> workflows. >> >> >> Matti > > Sorry for not being clear, when I was discussing modifications to scipy > I was referring to the specific use case of cross-compilation. The goal > is that existing native builds would not break backwards compatibility. > To that end, there's a package redirection stub in my PR for both > numpy.distutils and numpy.f2py. > > Just tried a native build using my current PR branch and at the moment > scipy doesn't work. However, it's a size mismatch during compilation as > opposed to an ImportError, so I probably just missed a subtlety when I > moved things. But I would definitely expect the finalized version of > this set of changes should not break existing users. > > Dustin
PR now builds unmodified scipy natively. Dustin _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
