On Sat, Apr 12, 2025 at 1:01 PM Nils Bruin <nbr...@sfu.ca> wrote: 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. >
Not if we follow your suggestion. If your proposed special configure option is enabled, which causes Sage to build its own python3 from source, then there is one and only one version of python which gets built from source -- one which is known to be acceptable to Sage. If that special option is not set then Sage does whatever it does to find an acceptable python on the system and use it. Those two courses of action are completely independent, except that when building from source the spkg must build a python3 which is acceptable to Sage. No one should ever be in a position where they accidentally trigger the build from source because the special "use at your own risk" configure option is required to trigger such a build. 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. > When you say "now" you are talking about what Sage already does, not what it would have to do if something were changed. Sage *does* support a wide range of "system" pythons, which indeed adds a maintenance load and restricts which python language features can be used in Sage code. The alternative (i.e. *always* building a specific python version from source) is not something that anyone has suggested. In fact, it is not a crazy thing to do, but it would be a departure from what is currently being done. I am not proposing that, and certainly no one else would propose such a thing. 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. > That claim is contradicted by the fact that upgrading from 3.12.5 to 3.13.3 required changing 4 lines of text in the spkg. And 3 of the 4 were completely obvious. 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. > But now that packaging work has been done (and is about to be trashed). The amount of new work involved in upgrading the "build from source" part of the spkg is trivial, as I just demonstrated. But please do not ignore what I said. I did not say that the python3 "build from source" option must be maintained forever. I said "Please keep it in place until there is a working, tested replacement ." Let me repeat the "Please" part. Please don't break our working build system before there is an actual working replacement. And, yes, when I say "working" I mean that it works for building a self-contained relocatable Sage which can be used for the Sage_macOS app. The status quo works by that definition. Leaving the "build from source" option in place, exactly as it is now, or with the addition of the configure option that you proposed, would make it continue to work by that definition. What does the Sage project gain by breaking our build when the alternative , i.e keeping the "build from source" option in place until there is a specific working alternative, has no cost? (And, by the way, "people install python somehow" is not a specific working alternative. It is not specific, it does not have a working implementation, and it is not really an alternative.) 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 > Not if the "build from source" route is protected by a special "use at your own risk" configure option. Add the "deprecated" tag to the "use at your own risk" tag if you like. - 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. > This is not an new risk. This is what you are currently doing. If you want to use "system" pythons from a wide range of linux distros then you need to support a wide variety of pythons, some of which will be new. (Arch linux comes with 3.13 and even has a 3.14 "pre-release" package available.) But no distro would ever use the Sage spkg to build python from source anyway. So this really has nothing to do with the topic. Nothing being discussed here would remove the existing requirement that Sage must support a wide variety of pythons, including new ones. - 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/CALcZXRE4MTS9mpKcf33SM%3DcngReDcA59TGdptVd2z-W%2BmRReYA%40mail.gmail.com.
