Forcing python39 on M1

[Todd Doucet]

Without intending to criticize any individual effort, I nevertheless respectfully suggest that something is less than ideal from a design & system standpoint, and I offer this because I think macports generally tries to get these high-level decisions architectural decisions right.

I think at core it is the assumption that to build successfully means, kind of, that it works.  This is much less true for complicated libraries, and more-or-less not true at all for libraries in languages like python, which rightly or wrongly push errors out to runtime instead of link time, or better yet, compile time.

In other words, that a python library like scipy "builds" is a nice first step, but means little by itself.  Python programmers know that that regression tests are not just a nice-to-have feature, but essential in their world.

Let us take the current scenario.  The Scipy library is (or was) broken on M1, and there is abundant discussion there about what the issue is and what the fixes might be, and people are implementing workarounds and redesigns, and what have you.

The problem, I respectfully suggest, is that somehow this gets all filtered out by the macports process and what you end up with is a "green" port that does not work.  And not because anybody is not doing, you say, what they are supposed to.  Because, apparently, a port maintainer is "not required" to run the regression test.

You might come to a different conclusion about what is desirable or practical for this, but I think you will agree that a well-known problem getting translated, by macports process, to a broken build that is advertised as working indicates that something is not quite right, and perhaps a tweak to the process could be considered.  And this is for something that is known not to work upstream.  If you see what I mean.

Thanks.



> On Mar 13, 2021, at 10:38, Todd Doucet wrote:
> 
> > 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.
> 
> I understand this is frustrating.
> 
> Apple Silicon is a new platform, and macOS 11 is a new operating system. Problems are bound to arise due to both. Each problem needs to be investigated and fixed individually. File bug reports with upstream if it is an upstream problem (i.e. if the software installs but doesn't work right). File bug reports with us if it is our problem (i.e. if we need to update to a new upstream version to fix a problem, or if upstream has fixed the problem but not yet made a new release and we can easily backport their change).
> 
> Green status on the ports web page means no errors were encountered the last time the build system tried to build that port. (This includes the condition where the port indicates that it is known to fail on that system. It would be more helpful if we could have a different color for this condition.) Red status means errors were encountered the last time the build system tried to build that port. The web page does not indicate whether the status information represents the most recently available version of the port.
> 
> The build system does not run any tests that a port may have. Ports are not required to have tests and port maintainers are not required to run tests prior to committing updates to ports. You can file a bug report to ask the maintainer to run the tests, but at best the maintainer has a similar enough system as you and sees the same problem when running the tests and can then file a bug report with the developers to get the problem fixed. You can save us time by filing the bug report directly with the developers yourself.
> 
> Remember that we are all volunteers. We work on what we can in our spare time. We also understandably often work on things that are of interest to us or that affect us. Many MacPorts contributors don't have Apple Silicon systems yet so haven't personally experienced whatever issues might exist there. Therefore we need either bug reports or pull requests from those who do have Apple Silicon systems to get things fixed.
> 
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20210313/59db39bf/attachment.htm>