Forcing python39 on M1

[Todd Doucet]

To be super-clear, the problems I am describing all relate to the M1 version of the python libraries.

> At some point I might try to determine whether I can get a useful python3 setup using Macports, but it is time-consuming and the status pages do not help, as the comments indicate.
> 
> When I tried a few weeks ago, I could install either py38 or py39, and that is fine if I want to write "hello world".  But to be useful, I need libraries like matplotlib, pandas, and and scipy.
> 
> But these packages were all available too, and marked happy green in the summary page.
> 
> But they do not actually work.  For example, scipy will quickly crash if you do most anything with it.
> 
> The cause is well understood upstream on the scipy site.  The bug is not caused by Macports.
> 
> But, really, it is hard for me to understand how these packages get a happy green label attached when all the build system, or the port maintainer, has to do is run the package-supplied regression test to see if it works.  And it does not.
> 
> As a user, it seems time-consuming and wasteful to install packages that do not work but claim to.  And it seems just too odd to file a bug report that essentially asks the port maintainer to run the regression test.
> 
> Maybe this all works now--I do not have the time to deal with it.  But perhaps my recent experience and frustration could be useful to others.
> 
> Here is what I presently do:  use the stock python from macOS and install local version of the libraries, then run all my code using the "arch -x86_64", which runs everything in x86 translation.  It actually works for everything I do and is only a bit slower than it would be otherwise (but still faster than my old x86).
> 
> It would be better to have a native arm64 version of the python stuff.  My understanding is that it is possible to cobble one together, and people have done that.  (Maybe the fratboys at brew have done that, not sure, I cannot bring myself to use brew.)
> 
> Eventually the upstream problems will be fixed and eventually there will be a macports version of it.  Until then, it would be useful to not report things working when they are not.
> 
> 
>> *Sigh*.  The ports.macports.org site has not been getting updates since Feb 20.  See recent threads.  Yes, this is *usually* reliable.  Not this month.
>> 
>> 
>> On Sat, Mar 13, 2021 at 8:23 AM Ken Cunningham <ken.cunningham.webuse at gmail.com> wrote:
>>> > Having heard that python39 is the only one (so far) to compile natively on M1, I’m trying to force the python ports I use to python39
>>> 
>>> Hello Peter,
>>> 
>>> FYI, an arm64 version of python38 appears to be available:
>>> 
>>> http://packages.macports.org/python38/python38-3.8.8_0.darwin_20.arm64.tbz2
>>> 
>>> and is “green” on the ports review page:
>>> 
>>> https://ports.macports.org/port/python38/summary
>>> 
>>> 
>>> The ports.macports.org page can be misleading at times, unfortunately, as it will show “green” if the port has been blocked from building even if it can’t be built, which is no doubt confusing to people at times and there is (I believe) a ticket about that somewhere.
>>> 
>>> The packages.macports.org site is pretty reliable, although to be 100% certain, you do need to actually install the port and examine it with “file” or “arch” or similar.
>>> 
>>> And the fact that the arm64 python38 exists doesn’t necessarily mean a universal python38 exists for x86_64/arm64 or can be built. It might or might not.
>>> 
>>> So there are some caveats to the presence of the python38 file there on packages, but it is there.
>>> 
>>> Best,
>>> 
>>> Ken
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20210313/50af89e9/attachment.htm>