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.web...@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 >
