Yes, by all means, please make giac optional. On Wednesday, February 19, 2025 at 5:40:03 PM UTC-6 Michael Orlitzky wrote:
> Hi, I've separated sage.libs.giac into its own package, and would like > to downgrade giac to optional at the same time the new package is > added, cf. > > * https://github.com/sagemath/sagemath-giac > * https://github.com/sagemath/sage/pull/39376 > > tl;dr now is the time to object. > > The reason for this, and the reason why I am working on this in the > first place, is because giac no longer builds and runs reliably. It > fails: > > * On riscv systems > * On systems with a hardened glibcxx > * On macos M2 (according to Volker) > * With gcc-15, due out in the next few months > > There is "inertia" with respect to getting any of these fixed. For > myself, the list above now covers 100% of the machines that I use on a > daily basis. And since libgiac is linked with sage, having giac as an > unconditional dependency makes it very difficult to use sage. > (Thankfully, giac is already optional when using meson to build sage.) > > On any of those systems, we need a way to disable giac and the > sage.libs.giac integration. That's the motivation for the new > package/PR. The remaining question is, do we leave giac and > sagemath-giac as standard, and tell everyone who experiences problems > to disable it? (We would also need a mechanism to disable it.) Or do > we make it optional, and let the people who use it enable it? > > Currently the PR makes it optional. I think there are some good > arguments for this: > > 1. It used to be optional a few years ago. We moved it into sagelib > to avoid a circular dependency between sagelib -> sagemath-giac > -> sagelib, but now there is no circular dependency. All integration > backends are "optional" because we run through the list and skip > any that don't return a result. > > 2. It's already optional when you use meson to build sagelib, so this > makes the two approaches consistent. > > 3. We don't lose any killer features, only a few clever integrals > that maxima/sympy can't solve. > > 4. It makes us look bad when things fail and we have to tell people > on the mailing list how to work around it. > > 5. Build time goes down. > > 6. Sage is less likely to break during "apt-get upgrade" or > equivalent. > > 7. If you want it back, "make sagemath_giac" or ./configure > --enable-sagemath_giac only take a minute. > > On the other hand the biggest downside is that if someone was using > libgiac directly in their own code or was relying on it for some > indefinite integrals, then they are probably going to be confused when > it isn't there in the next release. It's easy to fix, but they're > going to have to ask what happened first, and obviously that hits (4) > above too. FWIW I would write this all up in the release notes. > -- 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/89998397-62aa-4015-aad1-fb871e9c328cn%40googlegroups.com.
