On Mon, Apr 7, 2025 at 5:12 PM Marc Culler <marc.cul...@gmail.com> wrote: > > > > On Mon, Apr 7, 2025 at 3:25 PM Dima Pasechnik wrote: >> >> >> It's not standard - no-one nowadays builds Sage's Python, not even CI is >> doing this. >> >> This is the point I already made. >> You are the sole users of this semi-broken feature. > > > Well, it is a feature that is available by just setting one configure option, > and we have used the feature with Sage 9.3, 9.4, 9.5, 9.6, 9.7, 9.8, 10.0, > 10.1, 10.2, 10.3, 10.4, 10.5 and 10.6 without encountering a single failure > of the python3 spkg.
That's experience of the macOS app devs group, on macOS. Hardly a representative sampling. I could also say that building GAP from source is totally trivial and always works - I'm doing this for the last 30 years, therefore I know better! > Moreover you have not been able to produce an example of a build that failed > because of the python3 spkg. Marc, there are currently several support cases running, which would not be there if the ability to build Python/Python toolchain from source was absent in Sage. > Your macOS example had actually failed on a different spkg that gets built > before the python3 spkg, and the cause was a misconfigured homebrew > installation. Your Ubuntu 24.04 on WSL example failed in the same way when > the system python 3.12 was installed and available. Well, not really. E.g. https://groups.google.com/g/sage-devel/c/6wYRLYsfbG4 is talking about failures of building setuptools. But we already require setuptools to be available in the acceptable python3 from the system. That is to say, we can remove setuptools spkg as soon as we remove python3 spkg. Once again, let us just get out of business of vendoring Python and Python build toolchain, for it brings everybody nothing but pain, toil, and suffering. Hopefully we can get to work on enhancing maths capabilities of Sage instead... > So while I do observe that a lot of your time is being spent debugging Sage > build failures for users, and I certainly appreciate that effort, there seems > to be no evidence at all that removing the python3 spkg will reduce the > amount of that time. Moreover, Nils' proposal would prevent anyone from > accidentally using the python3 spkg, so that should ensure that none of the > build failures reported to the Sage project would be failures of the python3 > spkg. Obviously, if users use a ready toolchain we don't have to help them build one from source. Win-win situation, for them and for us. Besides, Nils' proposal would mean to introduce an entirely new kind of Sage package, and we already have far too many of these: standard, optional, experimental, dummy, base, pre-req, etc. are already there. Nils' proposal doesn't fit any of these. Instead of reducing the complexity of the spaghetti monster this proposes threading even more noodle through. Dima > > - Marc > > -- > 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 visit > https://groups.google.com/d/msgid/sage-devel/CALcZXRGQ7p3QPQpkzo3a-ZAeZaMiuU3mH0_igFGxmUY6E39Jsw%40mail.gmail.com. -- 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 visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq3K46sG-Jx5h7tUGPdav772OTcE71nTDZSO8kTSvv2tnQ%40mail.gmail.com.
