On Wednesday, 9 April 2025 at 12:15:07 UTC-7 dim...@gmail.com wrote: No, this won't fly. This is going to break the already fragile logic behind package types. Standard packages cannot be optionally installed, so it can't stay standard. Optional packages probably cannot appear in toolchain.
Presently python3 is a standard package, right? And most of the time the packages "succeeds" by not installing anything (because prerequisites are sufficient to provide what is wanted). Standard packages can also fail if hard prereqs are not met. We can have a standard package python3 that is simply a stand-in for ensuring that a sufficient python is provided. It looks like there is a particular scenario where python3 would behave differently, by actually installing python3 -- namely for building the MacOS app. It sounds to me that Marc is worried that satisfying the python3 requirement for the MacOS app is going to be fragile if it's not done through the standard package route that has been in place since the start of sage. That's more a confidence/trust issue than a technical issue. Hence, providing a smoother transition path may inspire more confidence in the participants. Your stated primary concern about the python3 package was that its attempt to build mask other prerequisite deficiencies in the build environment. Having a standard python3 package that by default only checks for the availability of a sufficient python but that can still build python3 if people really want would address your primary concern. So that should count as progress for you. At the same time, the concession that python3.spkg *can* still provide python if really wanted helps Marc see that the MacOS app build is taken seriously. I would expect it's a major delivery platform of sagemath functionality to users, so it should be taken seriously. Quite frankly, things like conda and uv are great initiatives and it would be great for sage to work nice with them. Conda is getting quite mature and has a wide user base, so transitioning to depending on conda may be a reasonable choice. Even if something strange happens to the organization behind Conda (those things tend to happen with open source initiatives on a fairly regular basis), I think at this point we can be fairly confident that it would get forked and remain reasonably supported. With "uv", on the other hand, I don't think there's the track record yet to convert to being dependent on it without alternatives. Slow transitions in build architecture decisions in mature projects are a feature, not a bug. -- 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/c9f1ff09-5e5c-4b48-b8c1-cc636dc05d3an%40googlegroups.com.
