On Friday, 11 April 2025 at 15:55:39 UTC-7 marc....@gmail.com wrote:
The obvious questions which this raises and which have still not been answered here are: What is so wrong with this process? Why do we have to break it? Why can't we at least leave the Sage spkg in place until there is an actual, tested, working replacement for it? (I am ignoring the other obvious question: what is so difficult about changing 4 lines of text in an spkg directory?) I get the impression that the concern is about maintenance load: when the project takes on the commitment to build python then it must update the python build package whenever this is required for supporting current operating systems. Apparently that clock ticks very quickly. So that requires frequent updates to the python package. Alternatively, the project could set python as a prerequisite and just build on top of that. It shifts what outside clocks we need to keep up with: now we need to ensure that we support a wide enough range of pythons so that it is easy for people to install a python that works on all current operating systems. I think the main function of having a build-from-source python package was to have a fall-back that allowed us to be very strict with our python requirements. It looks to me that the claim is that nowadays keeping a build-from-source python up to date is more work than keeping up-to-date with the python on which we run. In a way, python is supposed to be an abstraction layer: it packages a lot of OS functionality behind a common python interface. So in principle there's a benefit to just deal with that abstraction and leave it to the python packagers to support different underlying platforms. Of course, python's abstraction isn't perfect (or perhaps we break through it on purpose for performance reasons), so we might not get all of that benefit. What used to also be the case is that python itself would be quite in flux and that upgrading python from one version to another would need quite a bit of adjustment. I think that was why packaging python was generally deemed beneficial then. Python has grown considerably and hopefully has turned a lot more stable (and/or distributions have gotten better of supporting older version of python for longer), so it could well be that the calculus has changed on this. That's definitely the position I see Dima and William take. Certainly in the current situation of the python spkg we risk getting the worst of both worlds, if we want to do both well: - we need to ensure that the python spkg actually *can* build python on our supported platforms - we need to support a wide variety of pythons (including new ones) because people want the python spkg to be happy to have the python prerequisite satisfied by externally provided pythons. So I can see where the aversion to staying in this transitionary phase comes from. -- 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/2e338d21-1fac-4244-aa69-3c0bc7b8281dn%40googlegroups.com.
