On Tuesday, August 20, 2024 at 10:54:22 AM UTC-7 Nils Bruin wrote: What is currently not clear to me is *where* those binary wheels are going to come from
The upstream project is building them and depositing them on PyPI. and how we're going to test/ensure that they are available for the platforms that we commit to supporting. In the same way that we test everything else. https://doc.sagemath.org/html/en/developer/portability_testing.html It would also be good to think about what we're going to do if at some point we find that for one of our supported platforms such wheels are not available. Are we going to just drop that platform? We might have to. No. The very point of the policy proposed here is that only the *feature* that depends on the binary wheel can be disabled by a configure flag. So the portability of the whole project is not compromised. Or perhaps it's more advantageous to then "gracefully" reduce functionality and still provide sagemath for that platform; just not with the functionality that relies on the unavailable binary. Yes, that's exactly the point of the policy that I proposed. But then it becomes more like an optional prerequisite for enhancing functionality. Yes, the only difference between "standard packages that can be disabled" and "optional packages" is what the default is. I think the discussion is the important part here: by the looks of it reality is forcing the something like the policy on us, and we can't really vote that away. I'll note that the word "we" is doing a lot of the heavy lifting here. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/e503103c-85ae-46d3-95d0-c56ecb277873n%40googlegroups.com.
