On Fri, Apr 18, 2025 at 4:12 PM Nils Bruin <nbr...@sfu.ca> wrote: > > On Friday, 18 April 2025 at 10:07:12 UTC-7 dim...@gmail.com wrote: > > Nobody is going to "break" anything. You'll just need a proper Python to > install Sage, like one of many pre-reqs already needed. > It's just fear-mongering. Building Sage will be less broken this way, not > more broken. > > It looks to me that a consensus to move forward on this is in reach: > > * Dima's preference is to (eventually) end up in a state where python is a > prerequisite for sage and his main argument for that is: other projects have > as purpose to provide python and they likely do a better job than we'd do. > > * Marc and Sébastien have voiced some concerns about how smooth the > transition to "python purely a prerequisite" would be. Given that we HAVE > been offering the option to build python since the start, one would expect > that some people's workflows are relying on that behaviour, so there are > going to be wrinkles for those people. We in fact know that one example of > that is the building process of the MacOS app. > > It seems to me that the concerns of the two parties above aren't even > conflicting: one is aiming for something they find technologically superior > and ultimately more stable and reliable (and easier to maintain) whereas the > other party is concerned that the transition will be too painful for them, or > that they're forced to transition to something that may need fixing due to > unforeseen shortcomings that come to light once they go through this forced > transition. I haven't seen them object to the principle of the final goal. > > So a middle ground would be to offer a security blanket during the > transition: change the default behaviour of the python package for now to NOT > build, but as a transition measure offer a configuration flag that restores > the ability to build python from source. The clear goal of that must be that > within the near future, no-one is actually activating that configuration > flag, after which it can be removed with minimal impact. Once the python > package has become just a stub to test if there is a python available that > works properly, it will be easy to remove the package and instead make the > test for python a normal prerequisite check. >
If the proposal to require an external Python is accepted, there could still be our standard1-year deprecation period, during what you say above is done. > The perceived conflict here doesn't look like it's technological at all. It > seems much more an issue with trust. I realize it may be sobering to find > that people basically say: "I don't trust your assessment", but just shouting > "Just trust me" at an increased volume is very unlikely to persuade them. > Instead, if there's a way forward that allows you to say "Fine, you don't > have to trust me unconditionally; let's just do it in smaller steps and then > you can check for yourself it's OK", you'll likely to do much better on > gaining trust in the future. Plus, you'll arrive at the destination you were > aiming for eventually anyway. > > > -- > 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/a444cbd4-ff0b-4397-97ce-ad6da16f2679n%40googlegroups.com. -- William (http://wstein.org) -- 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/CACLE5GB1CtC16J__rqQXxDk%2B5DKwtuyH-VXj3fwKb8q%3D468vZA%40mail.gmail.com.
